Is it possible to reuse timerservice.schedule in my app under JBoss?
by Dmitry Savenko
Hello, everyone!
I'm writing an app which will work under JBoss AS 7, and I could find
a good use of "org.jboss.as.ejb3.timerservice.schedule" package, e.g.
CalendarBasedTimeout. I'm interested in parsing cron-like strings and
calculating future timeouts (Timer.getNextTimeout() isn't enough for
my purposes, since I need to know about further timeouts as well) Is
there a way to use this code besides of copy/pasting? I mean, may be
it's available as a separate library, or may I add it as a provided
dependency to my pom?
Best regards,
Dmitry.
12 years, 9 months
make <socket-binding>'s port optional
by Jeff Mesnil
Hi,
I am working on an issue in the domain model for HornetQ cluster
configuration[1].
To be configured properly, I want to specify only a multicast-address
and multicast-port but not the local port (and let the OS open one).
According to jboss-as-config XSD (and brian ;) ), it's correct, the port
attribute of socket-bindingType is indeed optional.
However, we had multiple places in the code where the port is considered
mandatory.
I have started to change these places to have a consistent semantic
between the XSD and the domain model but I have a test failing and I
can't figure out where is the code responsible for that.
In my branch, I have configured the messaging subsystem[2] with this
<socket-binding> (no port defined):
<socket-binding name="messaging-group" multicast-address="231.7.7.7"
multicast-port="9876"/>
But when I run the test suite, I end up with a standalone file[3] where
the port attribute is set to "undefined"
<socket-binding name="messaging-group" port="undefined"
multicast-address="231.7.7.7" multicast-port="9876"/>
Newbie question: where is the code in charge of generating the
standalone file from the messaging.xml subsystem? I am not yet familiar
with AS7 codebase...
AIUI, I need to make sure that if the port is not defined in the model,
it is not written to the XML either.
thanks,
jeff
[1] https://issues.jboss.org/browse/AS7-3881
[2] in build/src/main/resources/configuration/subsystems/messaging.xml
[3] in
testsuite/integration/smoke/target/jbossas/standalone/configuration/standalone-full-ha.xml
--
Jeff Mesnil
JBoss, a division of Red Hat
http://jmesnil.net/
12 years, 9 months
NPE in AS7.1.0 org.jboss.as.clustering
by William DeCoste
Hi Paul,
I don't see anything in JIRA for the exception below. I've run into this
a few times testing AS7.1.0. Please let me know if you want me to open a
JIRA.
Thanks -Bill
2012/03/15 13:17:24,568 INFO
[org.jboss.as.clustering.impl.CoreGroupCommunicationService.web]
(VERIFY_SUSPECT.TimerThread,web,c9fc3ab485-bdecoste8.dev.rhcloud.com/web) JBAS010254:
Suspected member: 7c4425909e-bdecoste8.dev.rhcloud.com/web
2012/03/15 13:17:25,327 ERROR
[org.jboss.as.clustering.impl.CoreGroupCommunicationService.web]
(Incoming-6,null) JBAS010245: ViewAccepted failed:
java.lang.NullPointerException
at
org.jboss.as.clustering.impl.CoreGroupCommunicationService$ClusterNodeFactoryImpl.getClusterNode(CoreGroupCommunicationService.java:1643)
[jboss-as-clustering-impl-7.1.0.Final.jar:7.1.0.Final]
at
org.jboss.as.clustering.impl.CoreGroupCommunicationService.translateAddresses(CoreGroupCommunicationService.java:1268)
[jboss-as-clustering-impl-7.1.0.Final.jar:7.1.0.Final]
at
org.jboss.as.clustering.impl.CoreGroupCommunicationService$GroupView.<init>(CoreGroupCommunicationService.java:1359)
[jboss-as-clustering-impl-7.1.0.Final.jar:7.1.0.Final]
at
org.jboss.as.clustering.impl.CoreGroupCommunicationService.processViewChange(CoreGroupCommunicationService.java:1168)
[jboss-as-clustering-impl-7.1.0.Final.jar:7.1.0.Final]
at
org.jboss.as.clustering.impl.CoreGroupCommunicationService$MembershipListenerImpl.viewAccepted(CoreGroupCommunicationService.java:1717)
[jboss-as-clustering-impl-7.1.0.Final.jar:7.1.0.Final]
at
org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.handleUpEvent(MessageDispatcher.java:506)
[jgroups-3.0.4.Final.jar:3.0.4.Final]
at
org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:545)
[jgroups-3.0.4.Final.jar:3.0.4.Final]
at
org.jboss.as.clustering.jgroups.ClassLoaderAwareUpHandler.up(ClassLoaderAwareUpHandler.java:56)
[jboss-as-clustering-jgroups-7.1.0.Final.jar:7.1.0.Final]
at
org.jgroups.blocks.mux.MuxUpHandler.passToAllHandlers(MuxUpHandler.java:156)
[jgroups-3.0.4.Final.jar:3.0.4.Final]
at org.jgroups.blocks.mux.MuxUpHandler.up(MuxUpHandler.java:123)
[jgroups-3.0.4.Final.jar:3.0.4.Final]
at
org.jboss.as.clustering.jgroups.MuxChannel$ClassLoaderAwareMuxUpHandler.up(MuxChannel.java:64)
[jboss-as-clustering-jgroups-7.1.0.Final.jar:7.1.0.Final]
at org.jgroups.JChannel.up(JChannel.java:716)
[jgroups-3.0.4.Final.jar:3.0.4.Final]
at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1026)
[jgroups-3.0.4.Final.jar:3.0.4.Final]
at org.jgroups.protocols.FRAG2.up(FRAG2.java:181)
[jgroups-3.0.4.Final.jar:3.0.4.Final]
at org.jgroups.protocols.FlowControl.up(FlowControl.java:418)
[jgroups-3.0.4.Final.jar:3.0.4.Final]
at org.jgroups.protocols.FlowControl.up(FlowControl.java:418)
[jgroups-3.0.4.Final.jar:3.0.4.Final]
at org.jgroups.protocols.pbcast.GMS.installView(GMS.java:625)
[jgroups-3.0.4.Final.jar:3.0.4.Final]
at
org.jgroups.protocols.pbcast.CoordGmsImpl.handleViewChange(CoordGmsImpl.java:247)
[jgroups-3.0.4.Final.jar:3.0.4.Final]
at org.jgroups.protocols.pbcast.GMS.up(GMS.java:784)
[jgroups-3.0.4.Final.jar:3.0.4.Final]
at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:244)
[jgroups-3.0.4.Final.jar:3.0.4.Final]
at org.jgroups.protocols.UNICAST2.up(UNICAST2.java:383)
[jgroups-3.0.4.Final.jar:3.0.4.Final]
at
org.jgroups.protocols.pbcast.NAKACK.handleMessage(NAKACK.java:730)
[jgroups-3.0.4.Final.jar:3.0.4.Final]
at org.jgroups.protocols.pbcast.NAKACK.up(NAKACK.java:559)
[jgroups-3.0.4.Final.jar:3.0.4.Final]
at org.jgroups.protocols.BARRIER.up(BARRIER.java:126)
[jgroups-3.0.4.Final.jar:3.0.4.Final]
at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:140)
[jgroups-3.0.4.Final.jar:3.0.4.Final]
at org.jgroups.protocols.FD.up(FD.java:273)
[jgroups-3.0.4.Final.jar:3.0.4.Final]
at org.jgroups.protocols.MERGE2.up(MERGE2.java:205)
[jgroups-3.0.4.Final.jar:3.0.4.Final]
at org.jgroups.protocols.Discovery.up(Discovery.java:354)
[jgroups-3.0.4.Final.jar:3.0.4.Final]
at org.jgroups.stack.Protocol.up(Protocol.java:358)
[jgroups-3.0.4.Final.jar:3.0.4.Final]
at org.jgroups.protocols.TP.passMessageUp(TP.java:1174)
[jgroups-3.0.4.Final.jar:3.0.4.Final]
at org.jgroups.protocols.TP$4.run(TP.java:1097)
[jgroups-3.0.4.Final.jar:3.0.4.Final]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
[rt.jar:1.6.0_22]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
[rt.jar:1.6.0_22]
at java.lang.Thread.run(Thread.java:679) [rt.jar:1.6.0_22]
--
Bill DeCoste
Principal Software Engineer, Red Hat
978-204-0920
wdecoste(a)redhat.com
12 years, 9 months
TCPPING in AS7
by William DeCoste
Hi Brian,
Has anything changed in the config of AS7.1 from 7.0.x? I am not seeing
any jgroups traffic or discovery. This configuration worked fine in
7.0.x. When JGroups is loaded it just creates 2 1-node clusters. They
don't seem to see each other or even be trying.
Thanks -Bill
<subsystem xmlns="urn:jboss:domain:jgroups:1.1" default-stack="tcp">
<stack name="tcp">
<transport type="TCP" socket-binding="jgroups-tcp"/>
<protocol type="TCPPING">
<property name="timeout">
3000
</property>
<property name="initial_hosts">
127.0.250.1[7600],127.0.251.1[7600]
</property>
<property name="port_range">
1
</property>
<property name="num_initial_members">
2
</property>
</protocol>
<protocol type="MERGE2"/>
<protocol type="FD_SOCK" socket-binding="jgroups-tcp-fd"/>
<protocol type="FD"/>
<protocol type="VERIFY_SUSPECT"/>
<protocol type="BARRIER"/>
<protocol type="pbcast.NAKACK"/>
<protocol type="UNICAST2"/>
<protocol type="pbcast.STABLE"/>
<protocol type="pbcast.GMS"/>
<protocol type="UFC"/>
<protocol type="MFC"/>
<protocol type="FRAG2"/>
</stack>
</subsystem>
--
Bill DeCoste
Principal Software Engineer, Red Hat
978-204-0920
wdecoste(a)redhat.com
12 years, 9 months
Re: [jboss-as7-dev] [infinispan-dev] AS7-4007 missing Infinispan dependency for clustered JPA second level cache
by Scott Marlow
On 03/06/2012 02:27 PM, Galder Zamarreño wrote:
> So, to summarise all of this. What I suggest is this:
>
> - Short term:
> The "quick fix" I suggest in http://lists.jboss.org/pipermail/infinispan-dev/2012-March/010317.html
Do we want to try this (requires a new build of Infinispan I think)? Or
should applications workaround the issue until we can reach the
medium/long term?
>
> - Medium term:
> Have a way to pass in marshalling configurations per cache manager and per-cache (or an abstraction of it), which allows the right class resolver to be passed in. (***)
> https://issues.jboss.org/browse/ISPN-1367
ISPN-1367 is targeted to Infinispan 5.2, any idea of the target release
date for that? I'm curious as to which AS release it might align with.
>
> - Long term:
> https://issues.jboss.org/browse/ISPN-1413
>
> (***) I still don't fully understand how web apps don't have the same issue as 2LC of not seeing Infinispan classes (Reminder: we're not talking about the contents of the cache, but about the Infinispan classes themselves).
https://github.com/jbossas/jboss-as/blob/master/web/src/main/java/org/jbo...
appears to be wired to use Paul's ClassLoaderAwareClassResolver.
>
> On Mar 6, 2012, at 8:19 PM, Galder Zamarreño wrote:
>
>>
>> On Mar 6, 2012, at 8:06 PM, David M. Lloyd wrote:
>>
>>> On 03/06/2012 01:02 PM, Galder Zamarreño wrote:
>>>> On Mar 6, 2012, at 6:31 PM, Paul Ferraro wrote:
>>>> </snip>
>>>>> To work around this, we typically store MarshalledValues in the cache - which are marshalled/unmarshalled using a marshalling configuration specific to the application (e.g. via a ModularClassResolver using the ModuleLoader of the deployment unit).
>>>>> https://github.com/jbossas/jboss-as/blob/master/clustering/api/src/main/j...
>>>>> https://github.com/jbossas/jboss-as/blob/master/clustering/api/src/main/j...
>>>>> https://github.com/jbossas/jboss-as/blob/master/clustering/api/src/main/j...
>>>>
>>>> Isn't a class resolver and a class loader, functionality wise, doing the same thing? I wonder if a custom classloader could not be built that delegates to a ModularClassResolver...
>>>
>>> No, not really. A class loader loads a class, given a name. But a
>>> class resolver loads a class given a name *and* stream information. The
>>> modular class resolver reads the stream information to know which class
>>> loader houses the class in question. This is critically important
>>> because it's possible (common even) for more than one class to exist in
>>> an AS instance with the same name. And there is no single class loader
>>> which has visibility to all classes which could potentially be stored in
>>> a cache.
>>>
>>> Yes, accepting a class loader to use is a powerful feature. However it
>>> *should* just be a convenience abstraction over a more fundamental
>>> feature which allows a class resolver to be set.
>>
>> Thanks for the clarification, makes sense.
>>
>> So, if I understand this correctly, Infinispan should really be enhanced to accept global and per-cache class resolvers, or more globally, as paul suggested below, marshalling configuration instances (or abstractions of them).
>>
>> I think https://issues.jboss.org/browse/ISPN-1367 should be reporpoused to do this.
>>
>>>
>>>>> So, essentially Infinispan itself only ever has to marshal/unmarshal a byte[] wrapper - so the AS has full control over the marshalling process.
>>>>>
>>>>> I would recommend that the 2LC do something similar, and include a mechanism for providing a MarshallingConfiguration per persistence unit.
>>>>
>>>> Possibly…
>>>>
>>>> --
>>>> Galder Zamarreño
>>>> Sr. Software Engineer
>>>> Infinispan, JBoss Cache
>>>>
>>>
>>>
>>> --
>>> - DML
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>> --
>> 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
>
> --
> 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
12 years, 9 months
JVM settings in domain mode
by Wolf-Dieter Fink
The adminGuide is:
====================================
JVM
The host controller contains the main jvm definitions with arguments:
|<jvms>|
|||<jvm name=||"default"||>|
|||<heap size=||"64m"| |max-size=||"128m"||/>|
|||</jvm>|
|</jvms>|
_(See domain/configuration/host.xml)
From the preceeding examples we can see that we also had a jvm
reference at server group level in the domain controller. The jvm's name
*must* match one of the definitions in the host controller. The values
supplied at domain controller and host controller level are combined,
with the host controller taking precedence if the same parameter is
given in both places.
Finally, as seen, we can also override the jvm at server level. Again,
the jvm's name *must* match one of the definitions in the host
controller. The values are combined with the ones coming in from domain
controller and host controller level, this time the server definition
takes precedence if the same parameter is given in all places.
==== But the facts are ===============================
1. the name MUST NOT match to host.xml <jvms><jvm name=""> definition
neither in server-group nor server
2. The host controller <jvms> definition will be overwritten by
server-group (not as described)
3. Q: if no jvm is set by SG and S the default will be 64-256
PermGen=128-128 where the defaults from? I expect value not set in java
command.
4. Q: if only one value is given (e.g. Host(xms=128 xmx=256)
Server=(xmx=512)) this value is overwritten)
So is 1. and 2. a bug or the new behaviour?
If this is a new behaviour the results of mixing jvm params might be
unexpected if the names dosn't match.
So can someone clarify what is the 'correct' way
I've tested with AS7.1.2.Final-SNAPSHOT today
- Wolf
12 years, 9 months
CLI command adding a security-domain does not work for me
by Wolf-Dieter Fink
I try to add a security domain with the command (review JB248 AS7 admin
course):
cd profile=full-ha/subsystem=security
./security-domain=JBTravel:add(authentication=[{"code"=>"Database","flag"=>"required","module-options"=>[("dsJndiName"=>"java:jboss/JBTravelDatasource"),("principalsQuery"=>"select
password from JTRAVEL.USER where username=?"),("rolesQuery"=>"select
null,'Roles' from JTRAVEL.USER where username=?")]}])
and I see => 'authentication' is not found among the supported
properties: [cache-type]
For me it looks correct, if I add the security-domain directly to the
domain.xml it will be correct, see below.
I test with EAP6.ER3 and 7.1.2.Final.
Am I wrong with the command (and my understanding of it)?
- Wolf
====== XML ====
<security-domain name="JBTravel">
<authentication>
<login-module code="Database" flag="required">
<module-option name="dsJndiName" value="java:jboss/JBTravelDatasource"/>
<module-option name="principalsQuery" value="SELECT password FROM
JBTRAVEL.USER WHERE username=?"/>
<module-option name="rolesQuery" value="SELECT null,'Roles' FROM
JBTRAVEL.USER WHERE username=?"/>
</login-module>
</authentication>
</security-domain>
=================
[domain@localhost:9999 subsystem=security]
./security-domain=JBTravel:read-resource
{
"outcome" => "success",
"result" => {
"acl" => undefined,
"audit" => undefined,
"authorization" => undefined,
"cache-type" => undefined,
"identity-trust" => undefined,
"jsse" => undefined,
"mapping" => undefined,
"authentication" => {"classic" => undefined}
}
}
12 years, 9 months
TCCL used EJBNamingContext is wrong when callstack passes through multiple OSGi modules
by Wollscheid. Steffen
Hi all,
we face the following problem:
We would like to be able to trigger a chain of events, say by JMX-Bean in on OSGi bundle [A].
[A] then calls up an OSGi Service/Class located in bundle [B] using an interface exported by [B].
Now [B] tries to make a remote EJB lookup into an ear [C] on an interface it imported from another OSGi Bundle [D].
This fails with the following stacktrace:
[Server:server-one] 15:46:32,245 ERROR [stderr] (RMI TCP Connection(4)-10.0.103.110) javax.naming.NamingException: Could not load ejb proxy class steffen.experimental.remote.ejb.RemoteCalculator [Root exception is java.lang.ClassNotFoundException: steffen.experimental.remote.ejb.RemoteCalculator from [Module "deployment.steffen.experimental.ejb-remote.twice-removed:0.0.1.SNAPSHOT" from Service Module Loader]]
[Server:server-one] 15:46:32,245 ERROR [stderr] (RMI TCP Connection(4)-10.0.103.110) at org.jboss.ejb.client.naming.ejb.EjbNamingContext.createEjbProxy(EjbNamingContext.java:108)
[Server:server-one] 15:46:32,246 ERROR [stderr] (RMI TCP Connection(4)-10.0.103.110) at org.jboss.ejb.client.naming.ejb.EjbNamingContext.lookup(EjbNamingContext.java:96)
[Server:server-one] 15:46:32,246 ERROR [stderr] (RMI TCP Connection(4)-10.0.103.110) at org.jboss.ejb.client.naming.ejb.EjbNamingContext.lookup(EjbNamingContext.java:76)
[Server:server-one] 15:46:32,246 ERROR [stderr] (RMI TCP Connection(4)-10.0.103.110) at org.jboss.as.naming.InitialContext.lookup(InitialContext.java:100)
[Server:server-one] 15:46:32,246 ERROR [stderr] (RMI TCP Connection(4)-10.0.103.110) at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:213)
[Server:server-one] 15:46:32,246 ERROR [stderr] (RMI TCP Connection(4)-10.0.103.110) at org.apache.aries.jndi.DelegateContext.lookup(DelegateContext.java:161)
[Server:server-one] 15:46:32,246 ERROR [stderr] (RMI TCP Connection(4)-10.0.103.110) at steffen.experimental.client.jmx.service.LookupImpl.internal_InitialContextService(LookupImpl.java:63)
[Server:server-one] 15:46:32,247 ERROR [stderr] (RMI TCP Connection(4)-10.0.103.110) at steffen.experimental.client.jmx.service.TriggerLookup.doAddition_InitialContextService(TriggerLookup.java:85)
[Server:server-one] 15:46:32,247 ERROR [stderr] (RMI TCP Connection(4)-10.0.103.110) at steffen.experimental.indirect.jmx.ServiceCallerWrapper.doAddition_InitialContextService(ServiceCallerWrapper.java:30)
[Server:server-one] 15:46:32,247 ERROR [stderr] (RMI TCP Connection(4)-10.0.103.110) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
Where "twice-removed" is [A] and the class TriggerLookup does reside in [B].
(We have aries.jndi running in our jboss, but the behavior described here occurs also without aries.jndi - in fact we had hoped that would solve our problems)
It is important to note, that the same code in [B] works alright, when the initiating JMX Bean resides in [B] instead of [A], because in this case the TCCL is bundle classloader of bundle [B], whereas in the other case it is the bundle classloader of [A] which of course has not knowledge of the interface class.
Furthermore it is important to note that this behavior occurs even though the flow of control from [A] to [B] is done using:
private TriggerLookupMBean getService(){
ServiceReference sRef = TwiceRemovedActivator.getBundleContext().getServiceReference(TriggerLookupMBean.class.getName());
if( sRef != null ){
return (TriggerLookupMBean) TwiceRemovedActivator.getBundleContext().getService(sRef);
} else {
throw new IllegalStateException("Service TriggerLookupMBean was not found!");
}
}
public String doAddition_InitialContextService()
{
return getService().doAddition_InitialContextService();
}
So that the OSGi framework would have a chance to change the TCCL using an interceptor hooked into the service which is returned by getService.
But from what I see simply an instance of the implementation class from bundle [B] is returned.
Am I doing something wrong here? Having aries.jndi installed, I can do a successful JNDI lookup for an OSGi Service regardless of the Bundle initiating the flow of control, while the same lookup, when done with a "ejb:" prefix fails.
This works:
AnOSGiService otherSvc = null;
ServiceReference sRef = Activator.getBundleContext()
.getServiceReference(JNDIContextManager.class.getName());
if (sRef != null)
{
JNDIContextManager contextMgr = (JNDIContextManager) Activator.getBundleContext().getService(sRef);
try
{
Properties props = new Properties();
props.put("osgi.service.jndi.bundleContext", Activator.getBundleContext());
Context ctx = contextMgr.newInitialContext(props);
System.out.println("doing JNDI lookup");
otherSvc = (AnOSGiService) ctx.lookup("osgi:service/" + AnOSGiService.class.getName());
System.out.println("lookup succeeded, calling service");
return "result:" + otherSvc.foo();
}
This fails:
RemoteCalculator calc = null;
ServiceReference sRef = Activator.getBundleContext()
.getServiceReference(JNDIContextManager.class.getName());
if (sRef != null)
{
JNDIContextManager contextMgr = (JNDIContextManager) Activator.getBundleContext().getService(sRef);
try
{
Properties props = new Properties();
props.put("osgi.service.jndi.bundleContext", Activator.getBundleContext());
props.put(Context.URL_PKG_PREFIXES, "org.jboss.ejb.client.naming");
Context ctx = contextMgr.newInitialContext(props);
System.out.println("doing lookup");
calc = (RemoteCalculator)ctx.lookup("ejb:application-ear-0.0.1-SNAPSHOT/ejb-definition-0.0.1-SNAPSHOT//CalculatorBean!steffen.experimental.remote.ejb.RemoteCalculator");
System.out.println("lookup succeeded, calling remote bean");
return "result:" + calc.add(1, 1);
}
As I mentioned before when called from a JMX-Bean in the same bundle both work!
What am I missing?
Our current workaround is an aspect that changes the TCCL in exported public methods if required - but I believe this should not be necessary.
Thanks for your patience reading this!
Sincerely
Steffen
...
SEEBURGER AG Vorstand/Seeburger Executive Board:
Sitz der Gesellschaft/Registered Office: Bernd Seeburger, Axel Haas, Michael Kleeberg
Edisonstr. 1
D-75015 Bretten Vorsitzender des Aufsichtsrats/Chairperson of the Seeburger Supervisory Board:
Tel.: 07252 / 96 - 0 Dr. Franz Scherer
Fax: 07252 / 96 - 2222
Internet: http://www.seeburger.de Registergericht/Commercial Register:
e-mail: info(a)seeburger.de HRB 240708 Mannheim
Dieses E-Mail ist nur f?r den Empf?nger bestimmt, an den es gerichtet ist und kann vertrauliches bzw. unter das Berufsgeheimnis fallendes Material enthalten. Jegliche darin enthaltene Ansicht oder Meinungs?u?erung ist die des Autors und stellt nicht notwendigerweise die Ansicht oder Meinung der SEEBURGER AG dar. Sind Sie nicht der Empf?nger, so haben Sie diese E-Mail irrt?mlich erhalten und jegliche Verwendung, Ver?ffentlichung, Weiterleitung, Abschrift oder jeglicher Druck dieser E-Mail ist strengstens untersagt. Weder die SEEBURGER AG noch der Absender ( Wollscheid. Steffen ) ?bernehmen die Haftung f?r Viren; es obliegt Ihrer Verantwortung, die E-Mail und deren Anh?nge auf Viren zu pr?fen.
The present email addresses only the addressee which it targets and may contain confidential material that may be protected by the professional secret. The opinions reflected herein are not necessarily the one of the SEEBURGER AG. If you are not the addressee, you have accidentally got this email and are not enabled to use, publish, forward, copy or print it in any way. Neither SEEBURGER AG , nor the sender (Wollscheid. Steffen) are liable for viruses, being your own responsibility to check this email and its attachments for this purpose.
12 years, 9 months
<deployments> section in standalone.xml
by Wolf-Dieter Fink
To be sure.
The deployments sections in standalone.xml (also in host.xml but here no
scanner) will be only used if the deploy is by management (CLI or
console) and
NEVER if the deployment-scanner pick it up from filesystem.
Right?
12 years, 9 months
JBOSS MODULES : How to create a new classloader at runtime using existing module + additionnal jars
by Philippe Mouawad
Hello,
I have the following requirement to implement:
- I have a server that:
- creates at runtime new classloaders that must see only parts of
the server classpath (kind of private ClassLoader):
- these new classloaders must not see each others
Reading and testing JBoss Modules it seems to me the solution to my issue.
I configured a set of modules and succeeded starting my Server with a
module.
Now I am trying to create dynamically the new classloaders which are
composed of :
- Server public API
- Set of JARs embedded in an archive and only visible to the newly
created ClassLoader
So my idea was to do the following:
- Create a new Module that would have as dependencies:
- the server module (which has only exported a subset of classes)
- a set of new JARs
So code would look something like:
ModuleIdentifier identifier = ModuleIdentifier.fromString("my new
class loader");
Builder builder = ModuleSpec.build(identifier);
DependencySpec dependencySpec =
DependencySpec.createModuleDependencySpec(
ModuleIdentifier.create("com.ubikingenierie.myserver"));
builder.addDependency(dependencySpec);
builder.addResourceRoot(ResourceLoaderSpec.createResourceLoaderSpec(
ResourceLoaders.createJarResourceLoader(
"name-of-jar1", new JarFile(new File("path to jar1")))));
builder.addResourceRoot(ResourceLoaderSpec.createResourceLoaderSpec(
ResourceLoaders.createJarResourceLoader(
"name-of-jar2", new JarFile(new File("path to jar2")))));
ModuleSpec moduleSpec = builder.create();
...> > What's next ??????
I am stuck here because I don't understand how from this to create the
ClassLoader as I need a Module Loader to build the Module then access
ClassLoader
And the issue is which one ? cause to get access to
"com.ubikingenierie.myserver" I need the root one which I could access like
this:
- Module mod =
((ModuleClassLoader)Thread.currentThread.getContextClassLoaderr()).getModule().getModuleLoader()
=> which is a LocalModuleLoader
But I don't see how to make it load my module , cause If I call loadModule
it won't find ""my new class loader" as it's not in it.
And If I create a new subclass of ModuleLoader I don't see how to make it
use LocalModuleLoader for existing modules.
I looked at ClassifyingModuleLoader which seemed to be a solution but I
don't understand how to use it (no doc , no test case ...)
Anyone can help ?
Thanks
Regards
--
Cordialement.
Philippe M.
12 years, 9 months
