Re: [jboss-user] [JBoss Microcontainer Development POJO Server] - Implementing a non-flat deployment for Weld Integration
by Flavia Rainone
Flavia Rainone [http://community.jboss.org/people/flavia.rainone%40jboss.com] replied to the discussion
"Implementing a non-flat deployment for Weld Integration"
To view the discussion, visit: http://community.jboss.org/message/543072#543072
--------------------------------------------------------------
> Ales Justin wrote:
>
> > So, Ales, how do you think this should be done? I think we have plenty of code in the ClassPools that do exactly that, mirror the ClassLoader structure in a way that allows us to find the classes and xml files in META-INF dirs. Maybe there is a way of reusing part of the ClassPool code to do this?
> It is similar in a way, but I don't see how you would be able to re-use it.
>
You are right. The point is that ClassPools contain the algorithm for finding Classes and other resources in the classpath. This means we need to take care of imports and exports and other complex stuff.
For WELDINT-1, all we need to do is to see the module hierarchy as you suggested, as that allows us to map the modules to BDAs and to yet see which BDAs are visible to a specific BDA.
The only thing that I see is duplicate here is RegisterModuleCallback/DomainRegistry. We need to keep track of modules and to map those to ClassLoaders. I'm duplicating this stuff for now, but we should definetly review this in the future.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/543072#543072]
Start a new discussion in JBoss Microcontainer Development POJO Server at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
15 years, 11 months
[JBoss Microcontainer Development] - Wildcard support in Dynamic-imports
by Ales Justin
Ales Justin [http://community.jboss.org/people/alesj] created the discussion
"Wildcard support in Dynamic-imports"
To view the discussion, visit: http://community.jboss.org/message/543069#543069
--------------------------------------------------------------
I've implemented an initial version of wildcard support.
e.g. Dynamic-import: com.acme.foo.*
When creating lazy delegate in Module (which we do for all dynamic requirements),
we differentiate between wildcards and plain dynamic import.
if (pr.isWildcard())
{
ClassLoaderPolicyFactory factory = new WildcardClassLoaderPolicyFactory(domain, item);
return new WildcardDelegateLoader(factory, filter);
}
Our wildcard policy tracks potential matching modules via ModuleRegistry notion from ClassLoading instance.
Hence wildcard factory registers the policy as a listener.
public ClassLoaderPolicy createClassLoaderPolicy()
{
WildcardClassLoaderPolicy policy = new WildcardClassLoaderPolicy(domain, requirement, module);
ClassLoading classLoading = domain.getClassLoading();
classLoading.addModuleRegistry(policy); // so we know when to reset on module change
return policy;
}
What our wildcard policy does is actually delegation to other existing matching modules.
public URL getResource(String path)
{
Module cached = resourceCache.get(path);
if (cached != null)
return cached.getResource(path);
ClassFilter filter = requirement.toClassFilter();
if (filter.matchesResourcePath(path))
{
for (Module m : modules)
{
URL url = m.getResource(path);
if (url != null)
{
resourceCache.put(path, m);
used.add(m);
return url;
}
}
}
return null;
}
"modules" list gets populated via tracking, where we only include potential matching modules.
public void addModule(Module module)
{
Domain md = getDomain(module);
if (md != null && module.canResolve(requirement))
{
boolean isAncestor = (domain != md); // not the same domain, so it must be ancestor
synchronized (this)
{
if (isAncestor)
{
if (domain.isParentFirst())
{
modules.add(0, module);
parentsBefore++;
}
else
modules.add(module);
}
else
modules.add(parentsBefore, module);
}
reset();
}
}
Same on removal, where we also try to bounce our module if we see that some module we used went away.
We also remove ourselves from module listening when undeploying.
public void removeModule(Module module)
{
synchronized (this)
{
if (modules.remove(module))
{
Domain md = getDomain(module);
boolean isAncestor = (domain != md);
if (isAncestor && domain.isParentFirst())
parentsBefore--;
reset();
}
}
boolean sameModule = this.module == module;
// Unregister this policy as module listener
if (sameModule)
{
ClassLoading classLoading = domain.getClassLoading();
classLoading.removeModuleRegistry(this);
this.module = null;
}
// It's not us (we're already uninstalling) and we used this, let's bounce.
if (used.remove(module) && sameModule == false)
{
LifeCycle lifeCycle = this.module.getLifeCycle();
if (lifeCycle != null && module.isCascadeShutdown() == false)
{
try
{
lifeCycle.bounce();
}
catch (Exception e)
{
throw new IllegalArgumentException("Error bouncing module: " + this.module);
}
}
}
}
Then comes the tricky part. :-)
Since the policy is mostly just used to find the matching resource, where its underlying classloader should do the real loading.
But in our case where we delegate all of the things, this needed some hacking into existing code.
To find the right ClassLoader I hacked BaseDelegateLoader's getBaseClassLoader method to protected (don't see why it should really be pckg protected), and then overriden it in WildcardDelegateLoader.
protected BaseClassLoader getBaseClassLoader(String message, String context)
{
ClassLoaderPolicy policy = getPolicy();
if (policy instanceof WildcardClassLoaderPolicy == false)
throw new IllegalArgumentException("Can only handle wildcard policy: " + policy);
WildcardClassLoaderPolicy wclp = (WildcardClassLoaderPolicy) policy;
return wclp.getBaseClassLoader(context);
}
Which then delegates to the policy with additional context parameter -- which is really the path of the requested resource.
BaseClassLoader getBaseClassLoader(String context)
{
Module m = findModule(context);
if (m != null)
{
ClassLoader cl = ClassLoading.getClassLoaderForModule(m);
if (cl instanceof BaseClassLoader)
return BaseClassLoader.class.cast(cl);
}
return null;
}
But the changes don't stop there, as the ClassLoadingManager/Task also asume there is a single matching classloader.
So, I introduced a new protected method on BaseClassLoaderPolicy.
/**
* Get the classloader based on classloading task.
*
* Since ClassLoadingTask ctor is package protected
* this method cannot be easily abused, since the only
* code that can instantiate ClassLoadingTask is our ClassLoaderManager.
*
* @param task the classloading task info
* @return the classloader
*/
protected synchronized BaseClassLoader getClassLoader(ClassLoadingTask task)
{
return getClassLoader();
}
Which is then overriden in wildcard policy.
protected BaseClassLoader getClassLoader(ClassLoadingTask task)
{
if (task == null)
throw new IllegalArgumentException("Null task");
String path = ClassLoaderUtils.classNameToPath(task.getClassName());
return getBaseClassLoader(path);
}
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/543069#543069]
Start a new discussion in JBoss Microcontainer Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
15 years, 11 months
[JBoss Portal] - Using more than one *object.xml
by Rekha Hari
Rekha Hari [http://community.jboss.org/people/rekhahari] created the discussion
"Using more than one *object.xml"
To view the discussion, visit: http://community.jboss.org/message/543068#543068
--------------------------------------------------------------
Hi,
I am trying to use more than one object.xml for configuring a portal, but I am having problem with that.
*file1-object.xml*
<deployments>
<deployment>
<parent-ref />
<if-exists>overwrite</if-exists>
<portal>
<portal-name>myportal</portal-name>
<page>
<page-name>pageone<page-name>
.....
<page>
</portal>
</deployment>
</deployments>
*file2object.xml*
<deployments>
<deployment>
<parent-ref>myportal<parent-ref>
<if-exists>overwrite</if-exists>
<page>
<page-name>pagetwo<page-name>
.....
<page>
</deployment>
</deployments>
If I copy the <page> tag in file2-object.xml into file1-object.xml then everything works fine, but the above does not work. Could you please tell me what I need to change to make the page definition in file2 also apprear in myportal.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/543068#543068]
Start a new discussion in JBoss Portal at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
15 years, 11 months
[JBoss Messaging] - JMSXDeliveryCount is not increased after client shutdown?!
by andreas_back
andreas_back [http://community.jboss.org/people/andreas_back] created the discussion
"JMSXDeliveryCount is not increased after client shutdown?!"
To view the discussion, visit: http://community.jboss.org/message/543041#543041
--------------------------------------------------------------
Hello!
When testing this JBoss Messaging the following behaviour is observed:
1. A message ist sent to the queue.
2. The message is processed in the onMessage method of a MessageListener in a client.
3. Within the onMessage method the JMSXDeliveryCount parameter is logged by msg.getIntProperty("JMSXDeliveryCount"); This first time the value is 1.
4. For testing purposes the client is shutdown (for example by Control-C under Linux or by shutting down the java process in the Netbeans IDE) while the onMessage method is processed.
5. After waiting more the 5 minutes the client is started again.
6. The original message is processed by the client again and msg.getIntProperty("JMSXDeliveryCount") returns the value 1 again.
*The question is:*
Are the parameters (perhaps in the messaging-service.xml) to influence JBoss Messaging to increase the JMSXDeliveryCount if the message is redelivered in this case of abnormal client termination?
Or is it bug in my thinking of what JBoss Messaging should do or in JBoss Messaging itself?
*The context of this question is the following*:
We are still not able to solve the problem that has been described in https://community.jboss.org/thread/151812 https://community.jboss.org/thread/151812
One idea was to set DefaultMaxDeliveryAttempts to 1 to let JBoss Messaging move messages into the dead queue if the messages are redelivered.
This does work if the client does call
(Session s).recover();
as it is done in the JMSXDeliveryCountTest class. If (Session s).recover() is called then the JMSXDeliveryCount is increased. This can be observed when the message is processed the next time and also in the JBM_MSG_REF.delivery_count attribute in the database.
It is essential for us to prevent the redelivery of a message that kills a service-unit (a client) as a result of a system error in the message processing within the client. Such a message could iteratively shutdown a whole array of service-units..
Thanks in advance,
Andreas
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/543041#543041]
Start a new discussion in JBoss Messaging at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
15 years, 11 months