November 2006 - jboss-dev-forums - Jboss List Archives

by david.lloyd＠jboss.com

Currently, the JSF Task Forms have a lot of requirements about the circumstances of their execution. For example, they assume that they are loaded from the /jbpm-console/participant/ path, so all their references are relative to there. They also assume the existance of "taskBean", the presence of certain images in the "../images" path, and the presense of "../css/jbpm.css". And finally, they rely on structural details of the taskBean, such as action methods. I propose that rather than having this information in the form (and thus putting significant restrictions on how the forms are displayed and used), each of those constructs could be replaced by a combination of a set of XML elements that perform each function, and using EL to import significant variables right into the task form space; for example, assuming an "tf" prefix for "task form": <img src="../images/formline.jpg" width="100%" height="24" border="0" alt=""/> Becomes: <tf:formline/> And: <input jsfc="h:inputText" value="#{taskInstanceBean.variables['paymentId']}" /> Becomes: <input jsfc="h:inputText" value="#{paymentId}"/> And finally: <input type="submit" jsfc="h:commandButton" id="transitionButton" action="#{taskInstanceBean.saveAndClose}" value="Save and Close Task"/> | <input type="submit" jsfc="h:commandButton" action="#{taskInstanceBean.save}" value="Save"/> | <input type="submit" jsfc="h:commandButton" action="#{taskInstanceBean.cancel}" value="Cancel"/> Becomes: <tf:transitionButtons/>...or can be left out altogether. Also, the task form need not include <h:form> tags, since this is really implicit; by providing this ourselves, we can add any hidden inputs we need to, and this frees the form designer from worring about the implementation details of the web application that utilizes the forms. Opinions? Also, one other unrelated problem is that some of the example task forms have multiple elements with the same ID, which is not allowed by either JSF or HTML. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3983792#3983792 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3983792

19 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: VirtualFile metadata

by scott.stark＠jboss.org

Then we have to ensure that the same vf instance is used in a given context. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3983754#3983754 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3983754

19 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: Web: ENC References

by scott.stark＠jboss.org

"anil.saldhana(a)jboss.com" wrote : Ok, I see that you fixed this issue with your commits. Want to ask a basic question (which may have been already asked before) | | | | <bean name="WarDeployer" class="org.jboss.web.tomcat.tc6.deployers.TomcatDepl | | oyer"> | | <property name="authenticators"> | | .... | | | | How do I invoke the getAuthenticators method on this bean in any arbitrary bean(pojo) in the MC? | | The war deployer would have to be injected or looked up via the kernel registry by the bean wanting to call the method. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3983749#3983749 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3983749

19 years, 5 months

1
0
0 / 0

[Design of EJB 3.0] - Re: Ejb3ClientDeployer handling j2ee14 clients

by scott.stark＠jboss.org

We have never required that Main-Class be specified. In the past you could run the client anyway you wanted. All that was required was the property jndi InitialContext factory. So you want a pre-check method that mirror the current lauch signature? That would be fine and cleans up the AppClientMain lauch loop. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3983746#3983746 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3983746

19 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: Make toplevel ear children deployments

by scott.stark＠jboss.org

Then why not add a VirtualFileFilter that defaults to this behavior that is used when there is no app xml. I still think we need to scan jars for annotations to further filter out those that should not be included to be fully ee5 compliant. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3983743#3983743 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3983743

19 years, 5 months

1
0
0 / 0

[Design of EJB 3.0] - Re: Integration with different JBoss Cache releases

by wolfc

We need the 1.4 stuff in branch 4.2 for as long as that hasn't switched. For SFSB I got the pieces of the puzzle here: http://wiki.jboss.org/wiki/attach?page=WolfC%2FEJB3Cache.png I think we should get a basic idea of where we're heading, so we don't run ourselves into the ground. We need different artifacts each with it's own dependencies which must never be circular. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3983703#3983703 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3983703

19 years, 5 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: libraries in an .ear file

by tom.baeyens＠jboss.com

for JEE 5 the lib directory seems indeed the way to go. but i want to concentrate only on J2EE 1.4 for now. ah... but we could already put the libs in a lib folder so that we are prepared for the jee 5 packaging :-) thanks! View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3983701#3983701 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3983701

19 years, 5 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: libraries in an .ear file

by andyredhead

Just had a look at the JEE 5 spec (JSR 244), section EE.8.1.2Application Assembly talks about how to put together .ear files and section EE.8.2Library Support goes on to describe how to include libraries. Option 2 in section 8.1.2: anonymous wrote : A .ear file may contain a directory that contains libraries packaged in JAR files. The library-directory element of the .ear file?s deployment descriptor contains the name of this directory. If a library-directory element isn?t specified, | or if the .ear file does not contain a deployment descriptor, the directory named lib is used. An empty library-directory element may be used to specify | that there is no library directory. | All files in this directory (but not subdirectories) with a .jar extension must be made available to all components packaged in the EAR file, including application clients. These libraries may reference other libraries, either bundled | with the application or installed separately, using any of the techniques described herein. Which sounds like what you are trying to achieve? That whole section is probably worth a read as it covers the whole ear assembly... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3983699#3983699 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3983699

19 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: Are you considering an OSGi based micro kernel ?

by c.vidal

Hi Sacha, Nice to meet you. Well actually, I would be very interested in implementing an OSGi deployer for JBoss on top of JBossMC. OSGi is really getting a lot of momentum and will definitely be a serious actor in the near future, some other J2EE servers seem to already be migrating their core to OSGi or tightly integrating it (WAS 6.1, JOnAS amongst others) and JBoss would definitely benefit from a tight integration with OSGi. Quickly as a first impression, the target functionalities I think would be great about that integration would be: - possibility to plug in any OSGi container (Equinox, Oscar, Knopflerfish, ...) - OSGi bundles would be automatically exposed as JMX Beans and/or JBossMC Beans - OSGi bundles could transparently benefit from J2EE services: JTA, JMS, EJB3, JPA, ... and maybe why not even clustering of OSGi services - OSGi bundles would be an alternative SAR deployment method That's a first rough draft. Is this the kind of integration with OSGi that you expect ? Regards View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3983696#3983696 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3983696

19 years, 5 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: libraries in an .ear file

by tom.baeyens＠jboss.com

C:\wsjbpm\jbpm.3_HEAD\enterprise\target>unzip -l jbpm.ear | Archive: jbpm.ear | Length Date Time Name | -------- ---- ---- ---- | 0 07/11/06 11:08 META-INF/ | 335 07/11/06 11:08 META-INF/MANIFEST.MF | 532 03/11/06 12:03 META-INF/application.xml | 3511 07/11/06 11:08 jbpm-configs.jar | 4726557 07/11/06 11:08 jbpm-console.war | 24768 07/11/06 11:08 jbpm-enterprise.jar | 664283 07/11/06 11:08 jbpm-jpdl.jar | 41395 07/11/06 11:08 jbpm-identity.jar | -------- ------- | 5461381 8 files View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3983683#3983683 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3983683

19 years, 5 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums November 2006