I have no problems querying mbeans.
Just added MBeanServerQuery class
| public class MBeanServerQuery
| {
|private Logger log = Logger.getLogger(getClass());
|private MBeanServer server;
|
|public MBeanServerQuery(MBeanServer server)
|{
| if (server == null)
You can probably combine the usage of
-
http://anonsvn.jboss.org/repos/jbossas/projects/jboss-deployers/trunk/deployers-client-spi/src/main/java/org/jboss/deployers/client/spi/DeployerClient.java
-
Which demo are you talking about?
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4195912#4195912
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4195912
___
jboss-user mailing list
[EMAIL PROTECTED] wrote :
| How can I hide the private bean?
|
You can try with scoped kernel / controller.
See tests on how to use this feature.
Or check PreInstallAction class on how this is applied.
View the original post :
Gary Marsh wrote :
| HDScanner - java.lang.NoSuchFieldError: factoryFinder
|
Where does this come from?
I searched for this 'factoryFinder' in demos, MC, AS, CL, Deployer w/o success.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4196000#4196000
Reply to
I just fixed aop-beans.xml.
Can you check if it works now?
ps: don't forget to set demos.home system property if the code is not in
\projects\demos
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4196010#4196010
Reply to the post :
Gary Marsh wrote : Was there something else besides the aop-beans.xml I
needed?
I just copied the aop-beans.xml from trunk.
But I updated the libs a few days ago - see top pom.xml.
I did a clean checkout, ran 'mvn idea:idea' to build up project files for
IntelliJ.
Adding JMXMain with models
ALRubinger wrote :
| No way to get private fields with a corresponding accessor/mutator read in?
|
Perhaps we should join the metadata on field and its accessor/mutator if the
BAM is FIELDS or ALL.
Or we can easily add new BAM - it just needs BeanInfoCreator.
View the original post :
Gary Marsh wrote : By the way I am using JRE 6 the latest release from Sun.
I don't know if this might be adding an element of difference that is confusing
us or not.
|
Nope.
Works fine:
| C:\Java\jdk1.6.0\bin\java -Didea.launcher.port=7532
It's this code:
| org.jboss.virtual.plugins.context.VfsArchiveBrowserFactory factory =
org.jboss.virtual.plugins.context.VfsArchiveBrowserFactory.INSTANCE;
| org.jboss.util.file.ArchiveBrowser.factoryFinder.put(vfsfile,
factory);
|
You need to set the correct BeanAccessMode for your bean.
By default we don't look into fields.
Either set bean's BeanAccessMode to FIELDS or ALL.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4195575#4195575
Reply to the post :
alr wrote : Is there a better way where this approach may be avoided?
Register BeanAnnotationAdapter singleton instance as MC bean.
Then add its add/remove plugin methods as callbacks.
And register your custom EJB plugin as MC bean as well.
It will be then auto-magically :-) picked up by BAA.
hgomez wrote :
| Any samples around?
|
Check jboss-classloading.xml tests -- jboss-cl sub-project.
Or jboss-dependency.xml tests -- jboss-deployers sub-project:
-
hgomez wrote : or if I could just use simple Pojos and still get the
start/stop/reload support ?
|
Sure, you don't need OSGi for this.
Plain MC beans ((-jboss)-beans.xml) + some class(loading)|generic dependency
does the trick.
View the original post :
Gary Marsh wrote : and I am assuming you provide comparable JMX functionality
(MBean notification, register and unregister, etc..). I look forward to
reading your documentation.
- http://www.jboss.com/index.html?module=bbop=viewtopict=143433
View the original post :
Gary Marsh wrote : what is the easiest way to get the source code for this
release (i.e. zip file).
|
It's all Maven-ized, so it's trivial to do a bunch of things.
e.g. IDE integration (I'm an IntelliJ user)
- mvn idea:idea
-
PeterJ wrote : You could run the svn command from a command line:
| svn co http://anonsvn.jboss.org/repos/jbossas/projects/microcontainer/trunk/
| That will get all of the sources.
|
No, this will only get the sources of MC's Kernel sub-project. ;-)
See MC home page for full list of
alesj wrote : I'll add BeanMetaDataBuilder::createContextualInjection method,
| which will hide this.
Done:
- https://jira.jboss.org/jira/browse/JBMICROCONT-401
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4194370#4194370
Reply to the post :
http
Gary Marsh wrote :
| When I try to download from svn using alesj's suggestion I get the
following error :
|
| svn: Your .svn/tmp directory may be missing or corrupt; run 'svn cleanup'
and try again
| svn: Can't open file
I'll check the NPE.
Trying to mock your case.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4194472#4194472
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4194472
___
jboss-user
Gary Marsh wrote :
| Is this class found in another jar or do I need to download and build from
some where else?
|
Looks like you've got some old jboss-common.
It's now called jboss-common-core and it definitely includes this class.
How else would the JBossAS boot. :-)
View the original
Quick check/hack,
what if you put import-all=false to classloading element?
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4194474#4194474
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4194474
alesj wrote : Quick check/hack,
| what if you put import-all=false to classloading element?
Although this should be there by default ...
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4194475#4194475
Reply to the post :
http://www.jboss.com/index.html?module
alesj wrote : I'll check the NPE.
| Trying to mock your case.
I've copied your xml config.
Running my demos boot, I don't get NPE.
ClassLoadingSpace:325 is used, but it's all fine.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4194479#4194479
Reply
alesj wrote : alesj wrote : I'll check the NPE.
| | Trying to mock your case.
| I've copied your xml config.
| Running my demos boot, I don't get NPE.
| ClassLoadingSpace:325 is used, but it's all fine.
Found it. ;-)
It's what I suspected in the first place - 1st post with import-all
[EMAIL PROTECTED] wrote : Just to clarify - I put import-all=false on both
of my deployments and the effect is unchanged...
On your deployments this is already false by default. ;-)
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4194535#4194535
Reply to the
bob.mcwhirter wrote :
| Yah, I looked at that too. Though, that requires extending the
ModificationType enumeration and registering a ModificationAction. Non-trivial
to try out a different ModificationAction, it would seem.
|
| Perhaps a ModificationType.ATTACHED and go looking for a
[EMAIL PROTECTED] wrote : Also it uses 'required=true' etc when it should
be using 'use=required'. I seem to recall reporting this before. :-)
|
| Can I commit a fix for this without screwing anything up?
Sure, go ahead.
I'll port it to branch then.
View the original post :
[EMAIL PROTECTED] wrote : So I guess I'm back to my original problem of
finding where that class went :)
|
It's still there:
-
btw: deployers go into deployers/
- file:/home/david/src/java/jbossas/trunk/build/output/jbos
s-5.0.0.GA/server/default/deploy/jboss-threads.deployer
Although they should work in deploy/ as well. :-)
View the original post :
Scott was seeing this here:
- http://lists.jboss.org/pipermail/jboss-dev-forums/2008-November/028087.html
Dunno what he did to fix it.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4194135#4194135
Reply to the post :
[EMAIL PROTECTED] wrote : Though I am starting to suspect that there is no
support for this currently.
You would be wrong. ;-)
I might even be offended as you doubt us. :-)
See constants usage:
-
What exactly do you wanna auto-wire?
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4193727#4193727
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4193727
___
jboss-user mailing
[EMAIL PROTECTED] wrote : So does that mean that any bean which I want to
pull constants from has to be managed?
It's all about beans.
Unless we had special constants treatment,
how else do you expect us to pull stuff from? :-)
But I guess this can be done generic:
- simply add constants
| BeanMetaDataBuilder builder = BeanMetaDataBuilder.createBuilder(...);
| builder.addPropertyMetaData(provider, new
AbstractInjectionValueMetaData());
|
OK, a bit more impl detail.
I'll add BeanMetaDataBuilder::createContextualInjection method,
which will hide this.
View the
[EMAIL PROTECTED] wrote : Unless access-mode=FIELDS implicitly grabs the
class instead?
Grabs class how?
We don't have any special static handling (via xml or BMDB).
OO != static. ;-)
And I don't see why we should have any special treatment,
the example I provided you is not a huge penalty.
But
alesj wrote :
| We don't have any special static handling (via xml or BMDB).
|
Apart from constructor::factory.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4193756#4193756
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode
Let's add all legacy one's we can think of,
otherwise users might be in for a surprise.
- .beans
- .spring
- ... ?
Adding a TODO - to remove them once this issue is fixed (do we have a JIRA?).
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4193691#4193691
A simpler use case would be constants in an interface. ;-)
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4193793#4193793
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4193793
___
[EMAIL PROTECTED] wrote : The most obvious mechanism to me is a ValueMetaData
that is comprised of a class and a field name.
The most obvious is value-factory:
| bean name=ConstantsProvider
class=org.jboss.demos.ioc.access.ConstantsProvider
| constructor
|
We already have this. ;-)
You can define this in jboss-structure.xml.
Its context element takes modification attribute.
It can either be temp, unpack or explode:
-
alesj wrote : Its context element takes modification attribute.
|
Eventually this is part of ContextInfo,
so you can pre-determine this yourself.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4193824#4193824
Reply to the post :
http://www.jboss.com
Sure.
I never said this was _not_ pseudo code. :-)
But I think you get my drift.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4193894#4193894
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4193894
bob.mcwhirter wrote : I'm finding this difficult to get right...
|
There might not be the modification type you're looking for.
But it's easy to add what ever you want. ;-)
And I also see types behave as I expected. :-)
You're welcome to impl top == 'I effectively want is just a top-level
bob.mcwhirter wrote :
| It's still a bootstrap scanner iterating deploy/'s children before
deployers/ has been fully install, I think. Having scan() wait at a barrier of
some sort until the DEPLOYERS phase is complete would seem a possible solution.
|
So, if I understand this correctly,
This is wrong forum for such questions,
see sticky here: http://www.jboss.com/index.html?module=bbop=viewtopict=106598
btw: why explicit NamingContextFactory, afaik plain JDK's InitalContext should
do the trick, as you're in the same app / same VM
View the original post :
bob.mcwhirter wrote :
| My RailsStructure deployer implements JEP. Additionally, I've added
setJarExtension( .rails ) on one of my parsing deployers (seems like a weird
place for it, honestly),
|
This mostly comes from our legacy usage.
e.g. -beans.xml was packed as .beans
my
bob.mcwhirter wrote :
| While HDScanner itself is a BOOTSTRAP bean, I assume it gets completely
start()'d and running before the DEPLOYER phase.
|
Not any more, it's part of deploy/ now (build trunk).
-
Weird, we've added JarExtensionProvider (JEP) for exactly this reason.
We usually have parser deployers that implement this interface.
e.g. BeanDeployer -- -beans.xml + JEP .beans (old extension)
I'll have a look, although I remember adding test for it.
btw: no need for install, as JEP is
alesj wrote :
| I'll have a look, although I remember adding test for it.
-
http://anonsvn.jboss.org/repos/jbossas/projects/jboss-deployers/trunk/deployers-vfs/src/test/java/org/jboss/test/deployers/vfs/matchers/test/JarExtensionsTestCase.java
View the original post :
http://www.jboss.com
bob.mcwhirter wrote :
| So, to me, it seems like a timing issue. The JarUtils.addJarSuffix(...)
happens soon enough for JARStructure to see and use it, but *not* soon enough
for the HDScanner/Profile/whatever that initially loads the deploy/ directory
and constructs the
I guess you're experiencing this:
- https://jira.jboss.org/jira/browse/JBAS-6117
This is similar what we had with jboss-minimal tests:
-
http://anonsvn.jboss.org/repos/jbossas/trunk/testsuite/src/main/org/jboss/test/jmx/shutdown/ExitOnShutdown.java
-
What's this got to do with Microcontainer?
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4192986#4192986
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4192986
___
jboss-user
We reached 2.0.0.GA, meaning all our sub-projects are GA.
Woohooo!
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4193034#4193034
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4193034
gcompienne wrote : So I have the feeling it could still highlight something
strange somewhere.
|
| But anyway, the given workaround ...
Actually I don't see this as a workaround. :-)
Although this is marked as workaround in mentioned JIRA issue.
It's a normal behavior on how you load
The classloader should be there,
since we only remove it from BMD once it's uninstalled:
-
http://anonsvn.jboss.org/repos/jbossas/projects/jboss-deployers/trunk/deployers-vfs/src/main/java/org/jboss/deployers/vfs/deployer/kernel/BeanMetaDataDeployer.java
In deployment phase it's removed here:
alesj wrote :
| I'm not saying its impossible, but I doubt it's us. ;-)
|
This doesn't mean I won't consider/accept a test case. :-)
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4192874#4192874
Reply to the post :
http://www.jboss.com/index.html?module
At first glance it looks good.
I'm lazy so I'll just ask, :-)
where's the info on how to setup this project:
- code checkout
- IDEA setup
- ...
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4192378#4192378
Reply to the post :
alesj wrote : alesj wrote : bob.mcwhirter wrote :
| | | @JMXObjectName
| | | public String myFancyObjectNameGeneratorOnMyMBean() {
| | | return cheese:name= + simpleName;
| | | }
| | |
| | This makes sense and can be easily added.
| |
| I'll let you
bob.mcwhirter wrote :
| I've attempted to add @JMX annotations, but got either a mixture of
nothing or already installed errors.
|
This should work.
I don't see how you can get nothing.
Or what are the exact already installed errors?
As mbean's ObjectName is derived from bean name,
hence
bob.mcwhirter wrote : or is there some way to wire things up to automatically
appear in JMX consoles?
And you can even add @JMX on a property.
-
http://anonsvn.jboss.org/repos/jbossas/projects/demos/microcontainer/trunk/models/src/main/java/org/jboss/demos/models/jmx/ExposePojo.java
This
Yeah, I thought that was the case.
Hmmm, but I remember we already did this.
I guess it got lost with xml + metadata transition to jbossxb.
I'll check.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4191758#4191758
Reply to the post :
bob.mcwhirter wrote :
| My already installed error occurs when I get the @JMX annotation on the
correct class, but give my object a bogus MC bean name (in this case
jboss.rails:name=oddthesis).
|
This is the code that creates the name:
-
bob.mcwhirter wrote :
| @JMXObjectName
| public String myFancyObjectNameGeneratorOnMyMBean() {
| return cheese:name= + simpleName;
| }
|
This makes sense and can be easily added.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4191876#4191876
alesj wrote : bob.mcwhirter wrote :
| | @JMXObjectName
| | public String myFancyObjectNameGeneratorOnMyMBean() {
| | return cheese:name= + simpleName;
| | }
| |
| This makes sense and can be easily added.
|
I'll let you implement it. :-)
Nah, just kiddin'. I'll try
bob.mcwhirter wrote : For what it's worth, it seems the instance-level
annotation capability was the solution.:
|
Nice.
Forgot you are 'inside' a deployer. :-)
bob.mcwhirter wrote :
| MC FTW!
|
FTW?
-
http://www.google.com/search?source=ighl=enrlz==q=define%3AFTWbtnG=Google+Searchaq=f
[EMAIL PROTECTED] wrote :
| Is this possible to do? Maybe even using SchemaResolverDeployer to produce
the custom metadata type, which is then handed to the program (perhaps with an
install callback)?
Sure, this is nothing abnormal.
We do this all the time.
e.g. EJB metadata -- JBossMetaData
[EMAIL PROTECTED] wrote :
| But we don't use this technique to configure/reconfigure the EJB Container
itself do we?
|
No, I would expect EJB Container to be a bunch of MC beans,
hence configurable via MC based ManagedObject.
[EMAIL PROTECTED] wrote :
| I thought that would be analogous
andrejt wrote : My hint would be to put the servlet transport request
higher up on the JBM priority list.
Go and vote for it in JIRA. :-)
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4191908#4191908
Reply to the post :
alesj wrote : I'll check.
http://www.jboss.com/index.html?module=bbop=viewtopicp=4191929#4191929
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4191933#4191933
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4191933
How to invoke JMS over port 8080 in JBoss 4.2.3?
With 4.0.5 I was able to do this
client -- JMS:
java.naming.factory.initial=org.jboss.naming.HttpNamingContextFactory
java.naming.factory.url.pkgs=org.jboss.naming:org.jnp.interfaces
timfox wrote : unless you have manually removed JBoss MQ and installed JBM.
|
Yes, manually removed.
But it's JBM 1.3. ;-(
Like you said, I'll try to upgrade to 1.4.(2).
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4191528#4191528
Reply to the post :
Running this
| !--
| HTTP Transport Example.
|
| $Id: messaging-http-service.xml 2773 2007-06-12 13:31:30Z sergeypk $
| --
| server
|
|mbean code=org.jboss.jms.server.connectionfactory.ConnectionFactory
|
alesj wrote :
| produces this missing dependency
|
| | --- MBEANS THAT ARE THE ROOT CAUSE OF THE PROBLEM ---
| | ObjectName: jboss.messaging:service=Connector,transport=http
| | State: NOTYETINSTALLED
| | Depends On Me:
| | jboss.messaging.destination:service
alesj wrote :
| Any setting that might tell it to use existing stuff?
|
timfox wrote :
| I believe JBoss Remoting provides a servlet transport which effectively
allows you to connect via tomcat
|
Yeah, as soon as I wrote this and turned off laptop, I though of this.
But due to JBM
[EMAIL PROTECTED] wrote : OK, so the rule is that SchemaResolverDeployers
must, must, MUST produce metadata that implements BMDF.
No. ;-)
The MD that maps to deployment's element must, must, MUST produce metadata
that implements BMDF.
e.g.
| deployment xmlns=urn:jboss:bean-deployer:2.0
|
StructureDeployers are ordered wrt relative order.
See VFSStructuralDeployersImpl::structureDeployers.
Their relative order is such that it makes sense.
e.g. declarative first, war ear before jar, file last
View the original post :
Like what?
KernelDeployment only cares about BMDF.
What this BMDF actually is or what it does it's up to you.
At the end all BMDs from those BMDFs are installed into Controller.
BMDB only deals with BMD,
actually the current impl deals with AbstractBMD.
The idea is to have your custom MD, which
alesj wrote : The idea is to have your custom MD, which implements BMDF,
| where its getBeans method uses BMDB extensively.
|
The idea behind BMDB is to hide impl details of how BMD is to be
created/assembled.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp
Hmmm ... actually I'm not really sure what JBossXB will do
if some wildcard deployment's element maps to MD which doesn't implement BMDF.
I would expect it to throw a useful exception. :-)
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4191428#4191428
Reply to
alesj wrote : Hmmm ... actually I'm not really sure what JBossXB will do
| if some wildcard deployment's element maps to MD which doesn't implement
BMDF.
| I would expect it to throw a useful exception. :-)
I did a quick check, this is the result:
| java.lang.ClassCastException
alesj wrote :
| JBossXB doesn't consider generics info -- see JBossXB's
CollectionPropertyHandler
http://www.jboss.com/index.html?module=bbop=viewtopict=146116
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4191435#4191435
Reply to the post :
http
We don't have repos defined in main pom.xml for a reason.
But we do have them in our settings.xml.
Afaik the reason is if we ever decide to change repo url/location,
instead of fixing n poms, we only fix settings.xml.
Read more about it here:
- http://www.jboss.org/community/docs/DOC-11358
View
ALRubinger wrote :
| Perhaps MC wants this code instead?
|
No. :-)
We're fine with our example.
The point of my example was to check
how easy it is to change classloading metadata.
What kind of behavior you put in it's entirely up to you.
e.g. in your case you also had to ignore roots
[EMAIL PROTECTED] wrote :
| What about some kind of mechanism to allow users to combine descriptors
into a single file?
You can already do this.
It's called 'urn:jboss:bean-deployer:2.0'. ;-)
| deployment xmlns=urn:jboss:bean-deployer:2.0
|bean name=blah
| ...
|/bean
mattlf wrote : Maybe there should not be a dot in the version number
MYPROJECT-JAR-1.0.spring ?
|
I doubt that dot is the cause.
How does your application.xml look like?
Perhaps you need to declare .spring jar as apps module:
(pseudo code, as it's been a while since I've done some real .ear)
[EMAIL PROTECTED] wrote :
| * a list of all classes in classpath archives with web-beans.xml files
|
Let me see if I got this.
yes == includes web-beans.xml
no == doesn't include web-beans.xml
e.g.
- myapp.ear
-- lib
--- ext.jar // yes
--- util.jar // no
-- first.jar // yes
-- second.jar
mattlf wrote :
| How to get the EAR to package the .spring ?
|
Unfortunately I'm not a Maven expert. :-(
Try asking this on maven forum.
Or perhaps our 'Build system' forum.
But I would expect it's a simple config detail you need to setup.
View the original post :
jimmyw83 wrote :
| Is there anyone that knows?
|
Perhaps me? ;-)
Read this (Guice-int is mentioned)
- http://java.dzone.com/articles/a-look-inside-jboss-microconta
to get familiar with the concept behind MC and its component model.
Module's tests are useful too:
-
jimmyw83 wrote : what it really do
It transparently binds MC beans with Guice beans and vice-versa.
See tests/article/presentation on how to do that.
I'll try to update to use Guice v2 asap,
since there are some useful dynamic features I was missing in v1.
View the original post :
mattlf wrote :
| I wonder if all JAR dependencies to MYPROJECT-IMPL.spring should also be
named as .spring ?
No, only the one's where you have jboss-spring.xml file in META-INF.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4189812#4189812
Reply to the post
mattlf wrote :
| 2008-11-17 17:43:45,552 14979 DEBUG 2008-11-17 17:43:45,632 15059 DEBUG
[org.jboss.deployment.EARDeployer] (main:) Extracted non-deployable content:
META-INF/jboss-spring.xml
| |
|
Why is this still in ear/META-INF?
mattlf wrote :
|
| | 2008-11-17
What did you try and didn't work?
Deployers are plain beans as all othe beans we install in jbossas or mc.
See multiple examples of this in jbossas instance's deployers directory.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4189654#4189654
Reply to the post
vickyk wrote :
| I have been trying to make the changes in the slee.deployer and then
placing the changed one in the jboss5/server/default/deployers folder, I was
expecting the new slee deployments will go through the changed deployers but it
did not.
|
What/where/how slee.deployer?
OK, I finally see what you mean. :-)
You actually mentioned this in your first post,
although it was still missing a small important detail.
No, deployers are not hot re-deployed.
Since we only scan deploy directory for changes.
You can drop you 'hot' deployer into deploy.
But then you must be
Not really sure.
My guess would be if it can be 'naturally' resolved,
then this should be doable.
I know Adiran hasn't fully finished / tested this:
-
http://anonsvn.jboss.org/repos/jbossas/projects/jboss-cl/trunk/classloading/src/main/java/org/jboss/classloading/spi/dependency/Domain.java
-
Yeah, you should have a .spring deployment in your ear:
- my.ear
-- some-beans.spring
--- META-INF
jboss-spring.xml
--- com/acme/beans/...
ps: this is a lot simpler in JBoss5 ;-)
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4189636#4189636
Reply to
emmartins wrote :
| What would be content of the class loading descriptor for the same class
loader as it is done by default (with no such descriptor) but with blacklisting
off.
|
Try this:
| classloading xmlns=urn:jboss:classloading:1.0 name=your-name-here
| export-all=NON_EMPTY
Have a look at my demos, its bootstrap to be exact:
- http://anonsvn.jboss.org/repos/jbossas/projects/demos/microcontainer/trunk/
See HDScanner class, its usage of files Map.
A bit more complicated impl is here:
-
[EMAIL PROTECTED] wrote :
| The returned SetClass? should comprise all classes which present in
this archive (and any sub-deployments it has e.g. in the war for an ear):
|
| * any web-beans.xml file in any root directory of the application
classpath,
| * any ejb-jar.xml file in any
301 - 400 of 893 matches
Mail list logo
