[Design of Messaging on JBoss (Messaging/JBoss)] - Re: .NET Client Conversion
by jesper.pedersen
Just my $0.02 as I have done this a couple of time - plus I wrote some of the Mono.Security.dll.
* Use properties
.NET developers find it very strange if simple attribute assignment should be handled through method calls. If there are additional checks/functionality involved with the assignment put that in the set{} method.
Of course there is a fine line when something should be moved a method - but as a general rule I found that properties are used when you operates on data that keeps the state of the object - where methods are used when you execute functionality.
* Use capital on the first letter for properties/methods.
Yep - this is different from Java ;) Small note, .NET doesn't (typically) expose any properties/methods that starts with Get/Set...
* Mono tool chain works great
I used Mono + NAnt + NDoc + NUnit for my work - and it worked great. I basically built a development environment as I would have done when coding Java. Of course the work I did on Mono.Security.dll was done on their branch following their rules. Deployment was .dll files that were then used by .NET developers using the M$ environment.
(And yes, the development was done because 1) M$ security dll didn't contain the needed functionality 2) license issues 3) support multi-platform development)
HTH - feel free to ask :)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4206558#4206558
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4206558
15 years, 2 months
[Design of POJO Server] - Re: Strange classloading behavior -- thread stuck
by adrian＠jboss.org
"bstansberry(a)jboss.com" wrote :
| Specifically, it's inside the "while (taskList.isEmpty() == false)" block, which leads me to question whether somehow the taskList is never empty. (Uneducated guess: somehow taskList == toTaskList, so this becomes a loop adding and removing threadTask???)
|
I'm also not totally sure how this code works either. :-)
It is a copy of LoadMgr3 from the UnifiedClassLoader which I tried to simplify
but couldn't get it work so I left it as it was. ;-)
But I don't believe taskList == toTaskList should ever be true.
The purpose of this loop is to reassign classloading tasks to other threads because
this thread has finished doing its classloading. It shouldn't be the "requestingThread"
on those classloading tasks. If it were, the nextTask() should have already done them.
Simplifying your second set of stack traces:
| Trace1:
| "Incoming-2,192.168.1.5:42274" prio=10 tid=0x0000000040353800 nid=0x2b3a runnable [0x000000003a2fc000..0x000000003a2ffb70]
| java.lang.Thread.State: RUNNABLE
| at java.lang.Object.notify(Native Method)
| at org.jboss.classloader.spi.base.ClassLoaderManager.unregisterLoaderThread(ClassLoaderManag
| er.java:127)
| - locked <0x000000001ce12608> (a java.util.Collections$SynchronizedList)
| - locked <0x000000001ce12608> (a java.util.Collections$SynchronizedList)
| at org.jboss.classloader.spi.base.BaseClassLoader.unlock(BaseClassLoader.java:1011)
| - locked <0x00000000199bace8> (a org.jboss.classloader.spi.base.BaseClassLoader)
| at org.jboss.classloader.spi.base.BaseClassLoader.unlock(BaseClassLoader.java:894)
| at org.jboss.classloader.spi.base.ClassLoaderManager.nextTask(ClassLoaderManager.java:289)
|
| Trace 2:
| "ajp-192.168.1.5-8009-2" daemon prio=10 tid=0x000000004575b800 nid=0x2b76 in Object.wait() [0x00000000028b6000..0x0000000002
| 8b9c70]
| java.lang.Thread.State: WAITING (on object monitor)
| at java.lang.Object.wait(Native Method)
| - waiting on <0x000000001dbed570> (a java.util.Collections$SynchronizedList)
| at java.lang.Object.wait(Object.java:485)
| at org.jboss.classloader.spi.base.ClassLoaderManager.nextTask(ClassLoaderManager.java:207)
| - locked <0x000000001dbed570> (a java.util.Collections$SynchronizedList)
| at org.jboss.classloader.spi.base.ClassLoaderManager.process(ClassLoaderManager.java:148)
|
| Trace 3:
| "Incoming-2,192.168.1.5:42274" prio=10 tid=0x0000000040353800 nid=0x2b3a runnable [0x000000003a2fc000..0x000000003a2ffb70]
| java.lang.Thread.State: RUNNABLE
| at java.lang.Object.notify(Native Method)
| at org.jboss.classloader.spi.base.ClassLoaderManager.unregisterLoaderThread(ClassLoaderManag
| er.java:127)
| - locked <0x000000001ce12608> (a java.util.Collections$SynchronizedList)
| - locked <0x000000001ce12608> (a java.util.Collections$SynchronizedList)
| at org.jboss.classloader.spi.base.BaseClassLoader.unlock(BaseClassLoader.java:1011)
| - locked <0x00000000199bace8> (a org.jboss.classloader.spi.base.BaseClassLoader)
| at org.jboss.classloader.spi.base.BaseClassLoader.unlock(BaseClassLoader.java:894)
| at org.jboss.classloader.spi.base.ClassLoaderManager.nextTask(ClassLoaderManager.java:289)
|
It's hard to tell without TRACE logging being enabled, but if Trace3 is really showing
that thread still looping from Trace1 then it looks your "uneducated guess" is correct.
i.e. Trace2 is showing a thread for the same classloader waiting on its thread task list
(0x000000001dbed570) while Trace1 and Trace3 is showing two locks on
(0x000000001ce12608).
| synchronized (taskList)
| {
| while (taskList.isEmpty() == false) // FIRST LOCK
| {
| ThreadTask threadTask = taskList.remove(0);
| ClassLoadingTask loadTask = threadTask.getLoadTask();
| Thread requestingThread = loadTask.getRequestingThread();
| if( trace )
| log.trace("Reassigning task: " + threadTask+" to " + requestingThread);
| threadTask.setThread(null);
| // Insert the task into the front of requestingThread task list
| List<ThreadTask> toTaskList = loadTasksByThread.get(requestingThread);
| synchronized (toTaskList) // SECOND LOCK
| {
| toTaskList.add(0, threadTask);
| loadTask.nextEvent();
| toTaskList.notify();
| }
| }
| }
|
So the issue is to try to figure out how that could happen.
If you know how to reproduce the problem, enabling TRACE logging
for org.jboss.classloader would help greatly. ;-)
I don't think your second guess is correct? The one about the remove
being outside the synchronized block. The code is the same as JBoss4.x
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4206557#4206557
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4206557
15 years, 2 months
[Design of JBoss Portal] - Caching
by bdaw
I added simple org.jboss.identity.idm.impl.cache.JBossCacheIdentityStoreWrapper class. It provides caching using JBossCache by simply wrapping any IdentityStore implementation. Wrapper can be configured on the repository level:
| <repository>
| <id>Repo1</id>
| <class>org.jboss.identity.idm.impl.repository.FallbackIdentityStoreRepository</class>
| <external-config/>
| <default-identity-store-id>Hibernate Identity Store</default-identity-store-id>
| <default-attribute-store-id>Hibernate Identity Store</default-attribute-store-id>
| <identity-store-mappings>
| <identity-store-mapping>
| ...
| </identity-store-mapping>
| <identity-store-mapping>
| <identity-store-id>LDAP Identity Store</identity-store-id>
| <identity-object-types>
| <identity-object-type>IDENTITY</identity-object-type>
| ...
| </identity-object-types>
| <options>
| <option>
| <name>cache</name>
| <value>true</value>
| </option>
| <option>
| <name>cache.config-file</name>
| <value>src/test/resources/jboss-cache-config.xml</value>
| </option>
| </options>
| </identity-store-mapping>
| </identity-store-mappings>
| <options/>
| </repository>
|
or:
| <repository>
| <id>Sample Repository </id>
| <class>org.jboss.identity.idm.impl.repository.WrapperIdentityStoreRepository</class>
| <external-config/>
| <default-identity-store-id>LDAP Identity Store</default-identity-store-id>
| <default-attribute-store-id>LDAP Identity Store</default-attribute-store-id>
| <options>
| <option>
| <name>cache</name>
| <value>true</value>
| </option>
| <option>
| <name>cache.config-file</name>
| <value>src/test/resources/jboss-cache-config.xml</value>
| </option>
| </options>
| </repository>
|
Main use case at the moment is to wrap LDAPIdentityStoreImpl. I will incorporate caching into this implementation later.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4206556#4206556
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4206556
15 years, 2 months
[Design the new POJO MicroContainer] - Re: Generated Classes not found if they do not match any of
by adrian＠jboss.org
"kabir.khan(a)jboss.com" wrote : "adrian(a)jboss.org" wrote :
| | You haven't answered why it is defined against the user classloader?
| | See my point about classloader leaks.
| |
|
| It is defined against the user classloader since as far as I can tell:
| -We cannot use the system classloader. The proxies use interfaces from the aop classloader (org.jboss.aop.proxy.container.AspectManaged and org.jboss.aop.proxy.container.Delegate) which are not visible from the system classloader.
| -We cannot use the aop classloader. The proxies might have interfaces introduced by the deployment, whose classloader might be in a child domain of the aop classloader's domain. Those interfaces would not be visible from the aop classloader.
|
| At the moment we are caching the generated proxies by deployment classloader. The classloader is the key into a WeakHashMap. If deploymentA wants to create a proxy for ArrayList with no interface introductions, we generate the proxy class using deploymentA's classloader. If deploymentB wants to create a similar proxy for ArrayList, we generate the proxy class using deploymentB's classloader. Subsequent attempts to get a plain ArrayList proxy from deploymentA's classloader will use deploymentA's cached class, and deploymentB will use deploymentB's cached class.
|
I guess I'm not understanding what you are doing. But what you described above
doesn't match what you originally said.
Above you have deploymentB using the proxy class from its classloader
but earlier you want it to see deploymentA's class?
If the proxy uses a deployment class then obviously it should be generated
against that deployments classloader. Other deployments then become dependent
upon that deployment and must be redeployed.
I don't see why the class can use the deployment class's package in that case?
But that doesn't sound like your original requirement which was to do "instrumenting
JDK classes" by creating classes in the base package.
anonymous wrote :
| Doesn't your point about classloader leaks hold for any deployment?
|
Yes, that's why you need to be careful with it. e.g. ejb3 had a big memory leak
while we were developing JBoss5 because it was defining remote/local proxies
against the wrong classloader.
If its as you say that deploymentB is using a class from deploymentA and that
is explicit then it is possible to know the dependency and redeploy.
Any other semantic will break the modularity and/or cause memory leaks.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4206545#4206545
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4206545
15 years, 2 months
[Design of JBoss Identity] - Injecting existing HibernateSession/SessionFactory
by bdaw
We had a discussion with TomB about JBPM needs and one of the important requirements is to inject existing Hibernate Session/SessionFactory.
At the moment design looks as follows:
1) The bootstrap method in IdentityStore creates HibernateEntityManagerFactory during initialization of the store.
| protected HibernateEntityManagerFactory bootstrapHibernateEntityManager(IdentityStoreConfigurationMetaData configurationMD) throws IdentityException
| {
|
| String persistenceUnit = configurationMD.getOptionSingleValue(PERSISTENCE_UNIT);
|
| if (persistenceUnit == null)
| {
| throw new IdentityException("Persistence Unit not defined for IdentityStore: " + getId());
| }
|
| return (HibernateEntityManagerFactory)Persistence.createEntityManagerFactory(persistenceUnit);
|
| }
|
Single instance of the IdentityStore (that reflect to one configuration piece) can be utilized by different repositories/realms so...
2) Each time the new IdentitySession is created it calls IdentityStore.createIdentityStoreSession() to get new IdentityStoreSession connected with the store. Then every time different realm call the same IdentityStore instance, IdentityStoreSession is passed to the IdentityStore methods inside IdentityStoreInvocation object. The actuall HibernateEntityManager object is there and HibernateIdentityStoreImpl retreives it from IdentityStoreSession context:
| protected HibernateEntityManager getHibernateEntityManager(IdentityStoreInvocationContext ctx) throws IdentityException
| {
| try
| {
| return (HibernateEntityManager)ctx.getIdentityStoreSession().getSessionContext();
| }
| catch (IdentityException e)
| {
| throw new IdentityException("Cannot obtain HibernateEntityManager", e);
| }
| }
|
Currently there is no direct way to pass the existing EntityManager. Direct workaround for now is to extend HibernateIdentityStoreImpl and override the bootstrapHibernateEntityManager method. It could be also possible to change IdentitySessionImpl and inject Hibernate Session object there.
Such possibility should be enabled by default so other possibilities I see are:
- Use JNDI to grab HibernateEntityManagerFactory.
- Enable other ways to bootstrap the whole framework - like MC. Then it should be easier to inject different components
One other problem is that currently HibernateIdentityStoreImpl uses both JPA and Hibernate annotations and therefore requires HibernateEntityManager. For projects that use plain hibernate (SessionFactory) it may rise a problem to provide HibernateEntityManager/Factory object. I see that hibernate EntityManagerFactoryImpl has a constructor that could be used:
http://www.hibernate.org/hib_docs/entitymanager/api/org/hibernate/ejb/Ent...
| EntityManagerFactoryImpl(org.hibernate.SessionFactory sessionFactory, javax.persistence.spi.PersistenceUnitTransactionType transactionType, boolean discardOnClose, Class sessionInterceptorClass)
|
I cannot confirm it is allowed/suggested/possible way of doing the conversion.
Probably the best way to go will be to just change HibernateIdentityStoreImpl to use plain hibernate without JPA annotations or classes.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4206495#4206495
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4206495
15 years, 2 months
[Design of POJO Server] - Re: The DeploymentManager and ProfileService
by emuckenhuber
"scott.stark(a)jboss.org" wrote : Maybe this could be a list/set of resolvers in the AbstractBootstrapProfileFactory so that its recursive logic still could be used to resolve both the profile and subprofiles across all of the resolvers. I'll work on this approach a bit.
Hmm okay - but there is also a ProfileFactory, so the resolver should either just resolve the ProfileMetaData
or use the ProfileFactory then - whereas there could also be more ProfileFactories, one for each profile meta data type.
Furthermore the AbstractBootstrapProfileFactory should actually do more than it's doing now.
There are some weird implicit dependencies set, to ensure the correct ordering during the bootstrap.
We might want to change this behavior, that the AbstractBootstrapProfileFactory also registers and activates
the Profiles based on the ordering in the xml and just keep explicit dependencies.
Therefore we might want to remove the automatic validation of Profiles in the ProfileService and let the caller decide when to validate.
So i'll do something else in the meantime and let you work on that a bit. I can continue later and finish the remaining stuff on my todo list.
This is also good so that you can check if you actually like my changes :)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4206457#4206457
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4206457
15 years, 2 months