Re: [jboss-dev] embedded jopr console in which configs?
by Shelly McGowan
Dimitris,
To Jaikiran's point, we saw no reason to exclude the distribution of the console
in the standard config even though we have seen issues with it:
https://jira.jboss.org/jira/browse/JBAS-6764
The issues noted in the JIRA are being verified in the revision targeted
for CR1 and should be resolved.
Shelly
----- Original Message -----
From: "Jaikiran Pai" <jpai(a)redhat.com>
To: dimitris(a)redhat.com, "JBoss.org development list" <jboss-development(a)lists.jboss.org>
Sent: Friday, April 24, 2009 8:29:44 AM GMT -05:00 US/Canada Eastern
Subject: Re: [jboss-dev] embedded jopr console in which configs?
Any specific reason, we want to limit it to "default" and "all"? By the
way, does the admin-console functionality in AS5 rely on the server
configuration having EJB support? I was thinking whether end users can
use the admin-console within a "web" server configuration (which does
not have EJB support).
-Jaikiran
Dimitris Andreadis wrote:
> As it is now it's in 'standard', 'default', 'all'.
>
> I'd thought we would only include it in 'default' and 'all' ?
>
> /D
> _______________________________________________
> 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
17 years, 1 month
EJB3 DevForum: Resource adapter file name hard coded into ejb3/MessagingContainer
by Clebert Suconic
I would rather use the forums for this... But I will use this list since
it is down.
Why the resource adapter is hard coded on
org.jboss.ejb3.mdb.MessagingContainer?
For instance i was going to rename it for JBM2, since we have our own
provider now, but i couldn't as there is this hard-coded instance. What
if the user was using another JMS provider besides JBM, JBM2 or JBossMQ?
It seems that this was supposed to be used around creating JMS
Destinations when deploying MDBs, but as far as I remember that feature
was Brocked long ago, so this code could probably be removed?
I couldn't understand back then the reasons for the Adrian Brocking it,
but it would be possible to do such thing on the resourceI would rather
use the forums for this... But I will use this list since it is down.
Why the resource adapter is hard coded on
org.jboss.ejb3.mdb.MessagingContainer?
For instance i was going to rename it for JBM2, since we have our own
provider now, but i couldn't as there is this hard-coded instance. What
if the user was using another JMS provider besides JBM, JBM2 or JBossMQ?
It seems that this was supposed to be used around creating non existent
when deploying MDBs, but as far as I remember that feature was Brocked
long ago, so this code could probably be removed?
I couldn't understand Adrian's reasons back then, but it seems
impossible to do it generically. If we want such thing we could
implement it on the ResourceAdapter, but I think it would be just better
to let the user aways deploy its destinations.
There are other references in two other xmls:
/jboss-5.1.0.CR1/server/default/deployers/ejb-deployer-jboss-beans.xml:
<!-- Destination creator for JBoss Messaging -->
<bean name="JBossMessageDestinationCreator"
class="org.jboss.ejb.deployers.CreateDestination">
<!-- We match any jms mdb that is going to be deployed using our
rar -->
<property name="matcher">
<bean
class="org.jboss.ejb.deployers.SimpleCreateDestinationMatcher">
<property name="default">true</property>
<property
name="messageListener">javax.jms.MessageListener</property>
<property name="rarName">jms-ra.rar</property>
</bean>
</property>
<!-- Create a destination with JBoss Messaging -->
<property name="factory">
<bean
class="org.jboss.jms.server.destination.JBossMessagingCreateDestinationFactory">
<property
name="serverPeerName">jboss.messaging:service=ServerPeer</property>
<property
name="postOfficeName">jboss.messaging:service=PostOffice</property>
</bean>
</property>
</bean>
jboss-5.1.0.CR1/server/default/deployers/metadata-deployer-jboss-beans.xml:
<bean name="JBossCustomDeployDUFilter"
class="org.jboss.deployers.vfs.spi.structure.helpers.VirtualFileDeploymentUnitFilter">
<constructor>
<parameter>
<bean class="org.jboss.deployment.FileNameVirtualFileFilter">
<constructor>
....
<entry>
<key>jms-ra.rar</key>
<value><null/></value>
</entry>
There are other references in two other xmls:
/jboss-5.1.0.CR1/server/default/deployers/ejb-deployer-jboss-beans.xml:
<!-- Destination creator for JBoss Messaging -->
<bean name="JBossMessageDestinationCreator"
class="org.jboss.ejb.deployers.CreateDestination">
<!-- We match any jms mdb that is going to be deployed using our
rar -->
<property name="matcher">
<bean
class="org.jboss.ejb.deployers.SimpleCreateDestinationMatcher">
<property name="default">true</property>
<property
name="messageListener">javax.jms.MessageListener</property>
<property name="rarName">jms-ra.rar</property>
</bean>
</property>
<!-- Create a destination with JBoss Messaging -->
<property name="factory">
<bean
class="org.jboss.jms.server.destination.JBossMessagingCreateDestinationFactory">
<property
name="serverPeerName">jboss.messaging:service=ServerPeer</property>
<property
name="postOfficeName">jboss.messaging:service=PostOffice</property>
</bean>
</property>
</bean>
jboss-5.1.0.CR1/server/default/deployers/metadata-deployer-jboss-beans.xml:
<bean name="JBossCustomDeployDUFilter"
class="org.jboss.deployers.vfs.spi.structure.helpers.VirtualFileDeploymentUnitFilter">
<constructor>
<parameter>
<bean class="org.jboss.deployment.FileNameVirtualFileFilter">
<constructor>
....
<entry>
<key>jms-ra.rar</key>
<value><null/></value>
</entry>
Clebert
17 years, 1 month
Modularizing JBossAS
by David M. Lloyd
Of the top ten goals listed for AS6 (as listed here:
http://www.jboss.org/community/wiki/JBossASTop10 ), at five will be
directly served by modularizing the AS. I think everyone is in full
agreement that it's something we can do, and something we should do. I
want to expand on some of the details of what it would entail.
It's apparent that the Java universe is moving towards a module-based
architecture. The question is, how do we want to distribute our modules?
We have two different module architectures available today. Thomas is
running full steam ahead on figuring out how to distribute our stuff as
OSGi bundles, and (as far as I understand anyway) the MC module system is
intended to be a functional superset of OSGi, which would enable us to
eventually integrate OSGi support directly into the MC. Neither route is
fully developed yet though, so I'd like to put forth a few basic
requirements for whatever module system we use.
They're listed here:
http://www.jboss.org/community/wiki/JBossAS6ModularizationRequirements but
I'll copy them inline.
Please comment on this thread or on the article. Don't be afraid to
comment even if you think it's redundant/stupid/whatever; and of course
don't hesitate to point out any misunderstanding/stupidity on my part.
Here's the first quick draft:
1. Most or all of the libraries distributed with JBAS should be
repackaged as modules.
1. This means that we'd need a way, on bootstrap, to
"retroactively" modularize anything on the boot classpath that has to be
available as a module at runtime. (Note: Any ideas?)
2. Modules will have strictly defined dependencies.
1. This means that deployments will only "see" APIs that they
depend on, and only the versions that they depend on.
2. This also means that more than one version of a module can be
present at the same time (theoretically anyway).
3. Module bundles should *not* have to be initially scanned on startup.
This will be critical to keep startup time sane.
1. We should be able to put 5000 modules in a common lib
directory, and not one of those files will be touched until some deployment
depends on one of them; then, only that module should be loaded, followed
by any of its dependencies.
2. This implies the need for some kind of ModuleLoader mechanism,
which is similar to a ClassLoader in that it will scan the filesystem to
load a module only when a specific module+version is requested, and it also
implies a connection between the bundle naming convention and the module
name (so that the loader won't have to scan a whole directory trying to
find a specific module).
4. For any given Class, it should be possible to identify its module
name & version (Note: I think we can do this today in jboss-cl).
- DML
17 years, 1 month
Reverted VFS to 2.2.0.M1 (& hudson madness)
by Jason T. Greene
Hi Everyone,
Since this weekends hudson meltdown seems likely related to a memory
leak, I have reverted VFS to M1. Recent updates to the VFS have been
observed to leak (JBAS-6805). This is potentially caused by a thread
safety issue introduced in M2. Shelly has kicked off another 5.1 testrun
with this update, and is checking to see see if M1 resolved 6805.
In the meantime I am working on an update to the VFS that does not have
the recent TS issues.
--
Jason T. Greene
JBoss, a division of Red Hat
17 years, 1 month
AS trunk testsuite wqn't build
by Brian Stansberry
Paul,
Beginning with
http://hudson.qa.jboss.com/hudson/job/JBoss-AS-6.0.x-testSuite-sun16/129/
the AS trunk testsuite won't build. Most likely because
jboss.server.classpath points to server/output which no longer has
content; content is in server/target
<!-- Server -->
<property name="jboss.server.root" value="${project.root}/server/output"/>
<property name="jboss.server.lib" value="${jboss.server.root}/lib"/>
<path id="jboss.server.classpath">
<pathelement path="${jboss.server.lib}/jboss.jar"/>
<pathelement path="${jboss.server.lib}/jmx-adaptor-plugin.jar"/>
</path>
Perhaps related to work on JBBUILD-520?
--
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberry(a)redhat.com
17 years, 1 month
Bootstrap Configuration Overrides
by Andrew Lee Rubinger
I'm in the process of reforming the JBossAS Configuration within the
Bootstrap Project.
Each configuration property may come from:
* Object model
ie. config.getJBossHome()
* System property
ie. -Djboss.home=/myJBossHome
* Configuration property
ie. config.getProperty("jboss.home")
* Environment Variable
(optional, ie. $JBOSS_HOME)
What do we think the order of preference should be in determining which
value is authoritative? I'm thinking the following rules:
System Property > Configuration Property > Object Model > Environment
Variable
...this means that anything may be overridden from the command line.
Environment variable comes last as it may be used to fall back on some
default. In truth all system properties get dumped into the
configuration properties upon config creation, so system props is a
subset of config props (more may be programmatically added to config
props after config creation).
If at the end of this chain a property is still unspecified, we'll set
it to some intelligent default, following a "convention over
configuration" paradigm.
Thoughts?
S,
ALR
--
Andrew Lee Rubinger
Sr. Software Engineer
JBoss, a division of Red Hat, Inc.
http://exitcondition.alrubinger.com
17 years, 1 month
