[Design the new POJO MicroContainer] - getInstanceClassFactory in ManagedObjectFactory
by alesj
Is this expeced behaviour:
I'm running some tests for BeanMetaDataICF:
| ManagedObjectFactory factory = ManagedObjectFactory.getInstance();
| BeanInstanceClassFactory instanceClassFactory = new BeanInstanceClassFactory();
| factory.setInstanceClassFactory(AbstractBeanMetaData.class, instanceClassFactory);
|
Which adds InstanceClassFactory for AbstractBeanMetaData.class.
But then I was getting weird NPE exception in BeanManagedDeploymentUnitTestCase.
AbstractManagedObjectFactory.getInstanceClassFactory was still holding weak ref for AbstractBeanMetaData.class, but the actual referent was null.
| public <T extends Serializable> InstanceClassFactory<T> getInstanceClassFactory(Class<T> clazz)
| {
| synchronized (instanceFactories)
| {
| WeakReference<InstanceClassFactory> weak = instanceFactories.get(clazz);
| if (weak != null)
| return weak.get();
| }
| return (InstanceClassFactory<T>)this;
| }
|
Adding try/finally to my BeanMDICF test did the trick.
| factory.setInstanceClassFactory(AbstractBeanMetaData.class, instanceClassFactory);
| try
| {
| ...
| }
| finally
| {
| factory.setInstanceClassFactory(AbstractBeanMetaData.class, null);
| }
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4096598#4096598
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4096598
18 years, 5 months
[Design of POJO Server] - Re: So what does unification mean for the ejb containers
by wolfc
"scott.stark(a)jboss.org" wrote : This looks ok, what is the problem?
| <xsd:schema xmlns="http://www.w3.org/2001/XMLSchema"
| | targetNamespace="http://www.jboss.com/xml/ns/javaee"
| | xmlns:javaee="http://java.sun.com/xml/ns/javaee"
| | xmlns:jboss="http://www.jboss.com/xml/ns/javaee"
| | xmlns:xsd="http://www.w3.org/2001/XMLSchema"
| | elementFormDefault="qualified"
| | attributeFormDefault="unqualified"
| | version="5.0">
No problem there, that's the easy part.
"weston.price(a)jboss.com" wrote : Again, I brought this up on one of our interminable meetings on Friday. Why are we including the Sun EE namespace in our stuff? Can't we simply use the Sun stuff as a base and then extend it?
If you mean creating extensions with javaee as the base like this:
<xsd:complexType name="jboss-resource-env-refType">
| <xsd:annotation>
| <xsd:documentation> The resource-env-ref element gives a mapping between the "code name" of a
| env resource (res-ref-name, provided by the Bean Developer) and its deployed JNDI name.
| </xsd:documentation>
| </xsd:annotation>
|
| <xsd:complexContent>
| <xsd:extension base="javaee:resource-env-refType">
| <xsd:sequence>
| <xsd:element name="jndi-name" type="javaee:jndi-nameType"/>
| </xsd:sequence>
| </xsd:extension>
| </xsd:complexContent>
| </xsd:complexType>
then you're back at the original problem, which is that the Sun xsds don't expose any elements.
So for example there is no jee:description that you can reference when building JBoss elements. Thus unmarshalling will get: org.jboss.xb.binding.JBossXBRuntimeException: {http://www.jboss.com/xml/ns/javaee}description not found as a child of {http://www.jboss.com/xml/ns/javaee}ejb-ref
Changing the xml will give: org.xml.sax.SAXException: cvc-complex-type.2.4.a: Invalid content was found starting with element 'jee:description'. One of '{"http://www.jboss.com/xml/ns/javaee":description,
| "http://www.jboss.com/xml/ns/javaee":ejb-ref-name,
| "http://www.jboss.com/xml/ns/javaee":ejb-ref-type,
| "http://www.jboss.com/xml/ns/javaee":home,
| "http://www.jboss.com/xml/ns/javaee":remote,
| "http://www.jboss.com/xml/ns/javaee":ejb-link,
| "http://www.jboss.com/xml/ns/javaee":mapped-name,
| "http://www.jboss.com/xml/ns/javaee":injection-target,
| "http://www.jboss.com/xml/ns/javaee":jndi-name,
| "http://www.jboss.com/xml/ns/javaee":ignore-dependency}' is expected.
| @ file:/home/carlo/work/metadata/target/eclipse-classes/org/jboss/test/metadata/ejb/JBoss50_testService.xml[16,30]
Thus ignore-dependency will have an jboss:injection-target, while resource-env-ref will have a javaee:injection-target. If javaee:injection-target was exposed, then ignore-dependency could ref that element and the world would be a better place.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4096557#4096557
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4096557
18 years, 5 months
[Design of JBoss Portal] - Default window state
by thomas.heute＠jboss.com
A popular feature request concerns having a default window state (maximized, minimized or a custom one)
Here are few proposals, all of them have advantages and drawbacks:
Proposal 1
| <page>
| <page-name>test</page-name>
| <window>
| <window-name>TestPortletWindow</window-name>
| <instance-ref>TestPortletInstance</instance-ref>
| <region>center</region>
| <height>0</height>
| <properties>
| <property>
| <name>navigation.initialState</name>
| <value>maximized</value> (or minimized, or a custom one)
| </property>
| </properties>
| </window>
| </page>
|
Proposal 2
| <page>
| <page-name>test</page-name>
| <window>
| <window-name>TestPortletWindow</window-name>
| <instance-ref>TestPortletInstance</instance-ref>
| <region>center</region>
| <height>0</height>
| <initial-state>maximized</initial-state>
|
| </window>
| </page>
|
Those 2 solutions are error-prone since you can define 2 windows as maximized (while a unique one can be). Bringing a random behavior.
Proposal 3
| <page>
| <page-name>test</page-name>
| <maximized-window>TestPortletWindow</maximized-window>
| <window>
| <window-name>TestPortletWindow</window-name>
| <instance-ref>TestPortletInstance</instance-ref>
| <region>center</region>
| <height>0</height>
| </window>
| <window>
| <window-name>TestPortletWindow2</window-name>
| <instance-ref>TestPortletInstance2</instance-ref>
| <region>center</region>
| <height>0</height>
| // Any of proposal 1 or 2 to define other modes like minimized or a custom one
| </window>
| </page>
|
The advantage is that you can only define 1 window as maximized per page.
It is mostly a hack just for maximized, it wouldn't help for a custom mode that has the unique constraint.
Proposal 4
| <page>
| <page-name>test</page-name>
| <initial-navigational-state>
| <state name="maximized">
| <window-ref>TestPortletWindow</window-ref>
| </state>
| <state name="minimized">
| <window-ref>TestPortletWindow2</window-ref>
| <window-ref>TestPortletWindow3</window-ref>
| </state>
| <state name="myCustomState">
| <window-ref>TestPortletWindow4</window-ref>
| </state>
| </initial-navigational-state>
| <window>
| <window-name>TestPortletWindow</window-name>
| <instance-ref>TestPortletInstance</instance-ref>
| <region>center</region>
| <height>0</height>
| </window>
| ...
| </page>
|
Here the advantage is to see the navigational state of a page in a concise way, it's easy to figure out if you have 2 windows in the same state, but error-prone to typos, and in that case you can define a window with 2 initial states (illegal).
I'm satisfied with none of those proposal, if you have better ideas or comments, please share :)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4096510#4096510
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4096510
18 years, 5 months
[Design of JBoss jBPM] - Re: Extension of the Designer
by koen.aers＠jboss.com
Hi Matthias,
Can you give some more information about what you are trying to do? More in particular:
- Can these actions occur anywhere (i.e. when any event is fired) or are they exclusively used within a generic node type?
- If its used in a node, does this node need to show up in the palette?
- Is it feasible to add specific xml elements for these actions you need? Or is it overkill?
- Is the custom configuration you want to do exclusively dependent on the classname of the action handler? Or are there other criteria as well?
We are slowly getting to node pluggability with the designer, and also action pluggability (custom predifined actions) is one of the things on the wishlist. So it seems your request falls in these categories.
It seems to me though that adding another configuration type is not the good approach. I would try to add a tabpage or a section on a tabpage in the properties view that contains entry fields for the needed configuration information. It would then be a matter of 'hiding' the default configuration properties pages. Could this work for you?
Regards,
Koen
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4096507#4096507
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4096507
18 years, 5 months
[Design of AOP on JBoss (Aspects/JBoss)] - Re: ClassLoading Module usage
by kabir.khan＠jboss.com
This now works locally. I've modified VFSTopLevelClassLoaderSystemDeployer to pass in the extra root
| public class VFSTopLevelClassLoaderSystemDeployer extends AbstractTopLevelClassLoaderSystemDeployer
| {
| @Override
| protected VFSClassLoaderPolicy createTopLevelClassLoaderPolicy(DeploymentContext context, Module module) throws Exception
| {
| ClassPathVisitor visitor = new ClassPathVisitor();
| context.visit(visitor);
| Set<VirtualFile> classPath = visitor.getClassPath();
|
| VirtualFile[] roots = new VirtualFile[classPath.size() + 1];
| int i = 0;
| for (VirtualFile path : classPath)
| roots[i++] = path;
|
| MemoryContextFactory factory = MemoryContextFactory.getInstance();
| VFSContext ctx = factory.createRoot(module.getDynamicClassRoot());
|
| URL url = new URL(module.getDynamicClassRoot() + "/classes");
| roots[i++] = factory.createDirectory(url).getVirtualFile();
|
| VFSClassLoaderPolicy policy = new VFSClassLoaderPolicy(roots);
| policy.setExportAll(module.getExportAll());
| policy.setImportAll(module.isImportAll());
| // TODO JBMICROCONT-182 more policy from "module"
| return policy;
| }
| }
|
Then in the JBoss5ClassPool I do
| public Class toClass(CtClass cc, ClassLoader loader, ProtectionDomain domain) throws CannotCompileException
| {
| lockInCache(cc);
| final ClassLoader myloader = getClassLoader();
| if (myloader == null || tempURL == null)
| {
| return super.toClass(cc, loader, domain);
| }
|
| try
| {
| String classFileName = getResourceName(cc.getName());
| URL outputURL = new URL(tempURL.toString() + "/" + classFileName);
| //Write the classfile to the temporary url
| synchronized (tmplock)
| {
| ByteArrayOutputStream byteout = new ByteArrayOutputStream();
| BufferedOutputStream out = new BufferedOutputStream(byteout);
| out.write(cc.toBytecode());
| out.flush();
| out.close();
|
| byte[] classBytes = byteout.toByteArray();
| MemoryContextFactory factory = MemoryContextFactory.getInstance();
| factory.putFile(outputURL, classBytes);
|
| clearCacheOnLoaderHack(myloader);
|
| return myloader.loadClass(cc.getName());
| }
| }
| catch(Exception e)
| {
| ClassFormatError cfe = new ClassFormatError("Failed to load dyn class: " + cc.getName());
| cfe.initCause(e);
| throw cfe;
| }
| }
|
I had to include a hack to clear the classloader blacklist:
| private void clearCacheOnLoaderHack(final ClassLoader loader)
| {
| if (loader instanceof BaseClassLoader)
| {
| try
| {
| AccessController.doPrivileged(new PrivilegedExceptionAction<Object>() {
|
| public Object run() throws Exception
| {
| Class clazz = loader.getClass();
| while (clazz != null && clazz != BaseClassLoader.class)
| {
| clazz = clazz.getSuperclass();
| }
| Field field = clazz.getDeclaredField("blackList");
| field.setAccessible(true);
| Set<String> set = (Set<String>)field.get(loader);
| set.clear();
| return null;
| }});
| }
| catch (PrivilegedActionException e)
| {
| // AutoGenerated
| throw new RuntimeException(e.getCause());
| }
| }
| }
|
Without clearing the black list, the new class is never picked up. Can we include a method to do this in the spi? We would not even need to clear the whole set, just a particular entry. The domain already has a method for this, but I need it on BaseClassLoader.
Another problem is if a generated AOP proxy is not in the same package as the proxied class (e.g. if the proxied super class is in the java.lang package, we create a proxy in the default package instead). This causes a problem since the underlying ClassLoaderDomain.classLoadersByPackageName does not get updated to include the default package, so the class is never found.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4096468#4096468
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4096468
18 years, 5 months
[Design of JBoss jBPM] - Extension of the Designer
by magro1202
Hi everyone, Hi Koen
i'm doing a diploma thesis at a company in Germany which is working with the JBPM Workflow Engine.
they want me to extend the Workflow Designer to have a possibility to specify an action node for their special issues.
At the moment they add specific Elements manually via XML-Editor, but
with complex Workflow structures this is not efficient and very error-prone.
the Elements they want to specify looks like this for example
There can be further elements within the "call" - Tag for example invoke or result parameters of an ant-script that is specified by scriptName
processVariables are global Variables within the Workflow that must be defined in an action node.
so my work is to implement a generic interface to be able do those configurations via the Designer
the idea is that with such an interface every user can load a specific definition in the designer to offer user dependant configuration of an action node.
For this i considered to create a new config-type for the action node e.g. "external" or "user defined" or the like.
when selected a user defined xml could be load in which the configuration elements are specified to be available in the designer
if such work is desired of a wide range of users one could transfer the results back to the Open Source Projekt
So my question is, does anyone have suggestions where in the code i have to make modifikations or extensions?
Or does anybody recommend a better way to do that?
Any comments are wellcome and would help me a lot
Regards
Matthias
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4096415#4096415
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4096415
18 years, 5 months