You can subscribe to this list here.
2005 |
Jan
|
Feb
|
Mar
|
Apr
(157) |
May
(789) |
Jun
(608) |
Jul
(554) |
Aug
(868) |
Sep
(654) |
Oct
(994) |
Nov
(803) |
Dec
(982) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2006 |
Jan
(1006) |
Feb
(1054) |
Mar
(1345) |
Apr
(1305) |
May
(1392) |
Jun
(1016) |
Jul
(265) |
Aug
(1) |
Sep
(8) |
Oct
(9) |
Nov
(8) |
Dec
(19) |
2007 |
Jan
(20) |
Feb
(10) |
Mar
(20) |
Apr
(8) |
May
(4) |
Jun
(1) |
Jul
(6) |
Aug
(3) |
Sep
(6) |
Oct
(12) |
Nov
(7) |
Dec
(13) |
2008 |
Jan
(5) |
Feb
(4) |
Mar
(34) |
Apr
(32) |
May
(22) |
Jun
(21) |
Jul
(30) |
Aug
(18) |
Sep
(30) |
Oct
(23) |
Nov
(86) |
Dec
(51) |
2009 |
Jan
(25) |
Feb
(26) |
Mar
(34) |
Apr
(47) |
May
(38) |
Jun
(25) |
Jul
(36) |
Aug
(9) |
Sep
(8) |
Oct
(10) |
Nov
(4) |
Dec
(17) |
2010 |
Jan
(7) |
Feb
(9) |
Mar
(26) |
Apr
(49) |
May
(52) |
Jun
(48) |
Jul
(39) |
Aug
(27) |
Sep
(9) |
Oct
(14) |
Nov
(7) |
Dec
(10) |
2011 |
Jan
(12) |
Feb
(9) |
Mar
(17) |
Apr
(33) |
May
(39) |
Jun
(36) |
Jul
(29) |
Aug
(26) |
Sep
(29) |
Oct
(38) |
Nov
(35) |
Dec
(27) |
2012 |
Jan
(20) |
Feb
(34) |
Mar
(29) |
Apr
(33) |
May
(45) |
Jun
(46) |
Jul
(50) |
Aug
(35) |
Sep
(55) |
Oct
(68) |
Nov
(79) |
Dec
(45) |
2013 |
Jan
(67) |
Feb
(20) |
Mar
(55) |
Apr
(52) |
May
(25) |
Jun
(25) |
Jul
(34) |
Aug
(27) |
Sep
(21) |
Oct
(21) |
Nov
(19) |
Dec
(12) |
2014 |
Jan
(10) |
Feb
(8) |
Mar
(13) |
Apr
(18) |
May
(36) |
Jun
(26) |
Jul
(17) |
Aug
(19) |
Sep
(13) |
Oct
(8) |
Nov
(7) |
Dec
(5) |
2015 |
Jan
(11) |
Feb
(2) |
Mar
(13) |
Apr
(15) |
May
(7) |
Jun
(2) |
Jul
(4) |
Aug
(3) |
Sep
(3) |
Oct
|
Nov
(2) |
Dec
(1) |
2016 |
Jan
(3) |
Feb
(5) |
Mar
(19) |
Apr
(34) |
May
(9) |
Jun
(10) |
Jul
(5) |
Aug
(10) |
Sep
(5) |
Oct
(11) |
Nov
(19) |
Dec
(7) |
2017 |
Jan
(4) |
Feb
(4) |
Mar
(8) |
Apr
(5) |
May
(12) |
Jun
(5) |
Jul
(11) |
Aug
(4) |
Sep
|
Oct
|
Nov
|
Dec
|
From: <ju...@jb...> - 2005-07-13 08:26:53
|
Marc, except wurfl (which is nice), there have been no real attempt to test JBoss Portal with wml devices. Someone started looking at it but it never went very far except the integration of wurfl. You should configure the request dumper valve in tomcat to look at the response generated by jboss portal. To do that, edit deploy/jbossweb-tomcat55.sar/server.xml and uncomment the line : | <!-- | <Valve className="org.apache.catalina.valves.RequestDumperValve" /> | --> | View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3884675#3884675 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3884675 |
From: MarcZ <nu...@jb...> - 2005-07-13 08:20:22
|
Hi, Can anybody help me with the content type text/vnd.wap.wml. I just want to see a simple 'HelloWorld" Portlet on my mobile device. I saw, that JBoss Portal uses wurfl. I configured the helloworld-jsp example. When I'm trying to access this portlet via mobile device emulator (Nokia) I got an Error 500, but no information in the log files. I also defined my own AbstractLayoutStrategy class for teh content type text/vnd.wap.wml. Does anybody have an example or hint, who to get run this example. Thanks View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3884673#3884673 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3884673 |
From: MarcZ <nu...@jb...> - 2005-07-13 08:16:14
|
Hi, I just want to know, if there is any posibility to import a couple og images to th CMS ? Can I do this, when I use the DB repository ? Is ther an API to import ? Thanks for your help. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3884670#3884670 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3884670 |
From: bstansberry <nu...@jb...> - 2005-07-13 05:24:25
|
Testing I would definitely want to add some unit tests to the JBoss testsuite for standalone session replication. I have tested it manually, but automated testing would be far superior. I believe it should be possible to get many of the existing unit tests to run in standalone mode as well. Here's what I'm thinking. Any comments from testsuite gurus or Tomcat gurus (or anyone else) would be much appreciated: 1) Testsuite build adds a target that builds up a minimal Tomcat installation in the testsuite/output folder. Most of the required pieces are already in the thirdparty module for use in the tomcat sar; would need to bring over a few more. Installation should include Tomcat's Manager webapp. 2) Testsuite adds a target(s) that is able to create a directory for use as a $CATALINA_BASE and programatically launch a Tomcat instance configured to use it. 3) Two such instances would be launched. 4) "Standalone" versions of the existing session replication test cases would be created. These would use the same test code, but instead of using the standard JBoss mechanism for deploying their war files into JBoss, a new version would be created that deploys the war files using HTTP calls to Tomcat's Manager webapp. If this seems like overkill or there is a simple way, please let me know :) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3884656#3884656 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3884656 |
From: riyaz_ahmed_mansur <nu...@jb...> - 2005-07-13 05:17:39
|
hi, when i am trying to invoke the mbean operation it thowing following exception. java.io.NotSerializableException: org.jboss.system.ServiceController$ServiceProxy at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1075) at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1369) at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1341) at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1284) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1073) at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1369) at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1341) at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1284) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1073) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:291) at java.util.LinkedList.writeObject(LinkedList.java:755) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:890) at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1333) at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1284) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1073) at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1369) at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1341) at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1284) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1073) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:291) at java.util.ArrayList.writeObject(ArrayList.java:569) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:890) at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1333) at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1284) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1073) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:291) at org.jboss.invocation.MarshalledValue.(MarshalledValue.java:57) at org.jboss.invocation.http.servlet.InvokerServlet.processRequest(InvokerServlet.java:150) at org.jboss.invocation.http.servlet.InvokerServlet.doPost(InvokerServlet.java:209) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at javax.servlet.http.HttpServlet.service(HttpServlet.java:810) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157) at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:75) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:186) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:214) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:198) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:152) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:66) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102) at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:150) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:462) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102) at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:54) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:137) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:118) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:929) at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:160) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:799) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:705) at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:577) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:683) at java.lang.Thread.run(Thread.java:595) what is the problem.. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3884655#3884655 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3884655 |
From: riyaz_ahmed_mansur <nu...@jb...> - 2005-07-13 05:00:28
|
hi all, i am trying to invoke the listDeployed() method.but it throwing exception like NotSerializableException. what is wrong with my code.. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3884653#3884653 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3884653 |
From: riyaz_ahmed_mansur <nu...@jb...> - 2005-07-13 04:59:50
|
hi all, i am trying to invoke the listDeployed() method.but i throwing exception like NotSerializableException. what is wrong with my code.. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3884652#3884652 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3884652 |
From: bstansberry <nu...@jb...> - 2005-07-13 04:59:30
|
Quick note on what's going on with this: Code basically along the lines discussed above has been checked into Branch_4_0 and HEAD. JBossCacheCluster has been changed in that it does not expose attributes to configure the TreeCache in detail (e.g. "isolationLevel", "cacheMode", etc.). Instead an attribute is exposed where the user can configure a relative path to a jboss-service.xml-style MBean deployment descriptor that configures the cache. If the attribute is not set, JBossCacheCluster will look for a file named cache-cluster.xml in the Tomcat conf folder. If no file is found, the TreeCache will be configured using reasonable defaults. No need to worry about a TransactionManager; DummyTransactionManager works fine. Using JOTM would be a mistake, as that would potentially involve session replication with user transactions. All of StandaloneJBossCacheManager's functionality has been merged into JBossCacheManager. JBossCacheManager can determine based on how it's configured whether its running embedded or standalone. JBossCacheManager handles deploying its ClusteredSessionValve itself; this has been removed from TomcatDeployer. The manager needs to be able to do this in standalone mode, so I saw no point in having the code duplicated. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3884651#3884651 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3884651 |
From: yxyang <nu...@jb...> - 2005-07-13 01:42:08
|
Currently, i didn't use CMS Portlet because i am not familiar with CMS portlet code(I only use a customized version of UserPortlet and customized ForumsPortlet.). So, i write a very simple portlet (HTMLJSPPortlet) myself which understand my IPC messages which are sent from navigationController(MenuPortlet). I didn't integrate my portlets into portal-core.war. Instead, i removed page definitions from portal-core.war. I have a mobmeee.war including all page definitions. I think this should be the way to go. I think portal-core should not define any pages, because pages are always used to present business of a specific portal installation. However, portal-core should include lots of very useful portlet or portlet-instance definitions so that third party developers like me to speed up the business. regards Yang View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3884643#3884643 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3884643 |
From: mholzner <nu...@jb...> - 2005-07-12 21:57:47
|
It would be nice if the portal did provide a facility to do things like a portal wide search. The way I'd invision this is as follows: * the portal publishes a set of supported features (like search), similar to the way modes and window states are published right now * the portlet publishes the features it supports (a subset of the ones provided by the portal) in jboss-portal.xml: (features that are not supported by the portal will be ignored) | <portlet> | ... | <features> | <doEvent/> | <doSearch/> | </features> | The portlet would need to implement additional interfaces that correlate with the feature, like | public Class MySearchablePortlet | extends GenericPortlet | implements JBPSearch { | .... | public SearchResult doSearch(SearchCriteria crit){ | // do something useful | } | } | Code that wants to search the portal could do that at various scopes: | Context ctx = new PageContext(); // current Page | // Context ctx = new PortalContext(); // current Portal | // Context ctx = new PageContext("portal:portalName/page:pageName"); // specified Page | List searchablePortlets sp = (List)ctx.lookup("java:comp/feature/search"); | for (Iterator i=sp.iterator();i.hasNext(); ){ | PortletSearchLink link = (PortletSearchLink)i.next(); | SearchResult result = link.execute("some criteria"); | html.append(result.toLinkURL().toString()); | } | // or List searchResults = PortalSearch.execute(sp, "some criteria"); | similarly events could be handled: | | public void processEvent (PortletEvent ev){ | ev.getParameterNames(); | ev.setRenderParameters(); | ev.setPortletMode(Mode.VIEW); | ev.setWindowState(State.NORMAL); | ev.getSession(Session.APPLICATION_SCOPE).setAttribute("blah", "blahblah"); | } | Events can only be fired from action requests of another portlet. process event is very similar to processAction, except that it only has a subset of the ActionRequest functionality available (there is no Response) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3884601#3884601 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3884601 |
From: mholzner <nu...@jb...> - 2005-07-12 21:31:45
|
As initiated by Julien today via chat, here are some thoughts about how this could be done (credit for the good parts goes to Julien; my ideas are the wacky ones ;) any portlet can specify a dependency to another portlet via its descriptor (jboss-portal.xml), like so: | <portlet> | .... | <portlet-link> | <link-name>INeedYou</link-name> | <portlet-name>Name of the portlet that is linked to as it appears in the portlet.xml</portlet-name> | <link-type>render|action|event</link-type> | </portlet-link> | </portlet> | The portlet itself would contain code like: | Context ctx = new PageContext(); // other contexts or scopes possible here ...? | try{ | PortletLink link = ctx.lookup("java:comp/portlet/INeedYou"); | link.setParameter("blah", "blahblah"); | html.append(link.toString()); | // and for event links ; only in processAction of the initiating portlet | if (link instanceof EventLink){ | ((EventLink)link).fire(); | } | }catch(UnsatisfiedLinkException e){ | // link was not provided, recover somehow | // provide base functionality without the links and events | } | For this to work, the portal needs to provide a mechanism that 'encourages' the user /admin to provide the resolution for the link when the portlet is being assigned to a page. What seems to make sense is that the tool would list all portlets on the page that this portlet is in the process of being assigned to , and let the user choose which one to link to. A type check would be possible based on the portlet name in the link definition. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3884599#3884599 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3884599 |
From: andrejt <nu...@jb...> - 2005-07-12 20:08:46
|
Yang, "yxyang" wrote : | For third party developer like me, it is inconvenient to modify the CMSPortlet code and do maintainence. | in your portal www.mobmeee.com however I can see that you have customized Login and Register (User portlet) from portal-core.war. Am I right? Have you integrated your portlet into portal-core.war in order to achieve inter-portlet communication between your menu portlet and jbp portlets? Thanks, Andrej View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3884588#3884588 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3884588 |
From: <ad...@jb...> - 2005-07-12 19:00:21
|
"sco...@jb..." wrote : | The biggest compatibility issue are the eclipse classpath entries. Someone can write another visitor that generates the project eclipse classpath when thirdparty is build instead of relying on cvs versions. | This already exists as part of the "synchronize" in the new build, but it has been broken by all the refactoring. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3884579#3884579 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3884579 |
From: <sco...@jb...> - 2005-07-12 18:50:14
|
I'm inclined to not checkin the thirdparty contents into cvs and to simply change the directions for building 4.0.3+ to include using the jboss-4.0.x cvs alias. The first dependency of the jboss-4.0/build/build.xml should be to build the thirdparty contents based on the build-thirdparty.xml. The libraries.ent file should be an artifact generated in the thirdparty directory and the scripts should be updated to use this version. The source release associated with a dist would continue to include the thirdparty contents so that its a self contained bundle. The biggest compatibility issue are the eclipse classpath entries. Someone can write another visitor that generates the project eclipse classpath when thirdparty is build instead of relying on cvs versions. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3884578#3884578 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3884578 |
From: mikezzz <nu...@jb...> - 2005-07-12 17:10:46
|
I think 2 & 3 are the same (MDBs are entry points in their own special way :-). Sending an 'couldn't deliver' email is exception handling rather than an a type of exception. I see these as 2 orthoginal concepts. I am happy to use RuntimeExceptions for all exceptions, but would like to have seperate base exceptions to distingush different types. Looking closer at the protocols I see what you mean about the conversation state stuff. However if we choose to handle the error locally then we should make sure something useful is returned to the caller. Either return a valid object or throw an exception. We shouldn't swallow the exception, log it and return null. There are few cases where this happens and the protocol gets into an unknown state, throws a null pointer exception and falls over in a heap. Also people tend to forget to check for nulls (I know I do). Cleanliness will hopefully be a result of a consistent approach. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3884561#3884561 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3884561 |
From: mikezzz <nu...@jb...> - 2005-07-12 16:44:15
|
Re: izPack, cool, will we be seeing it in M3? Re: Performance testing, I agree. Micro benchmark for critical code section should be unit tests. I think the term I should of used was load/scalability testing. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3884556#3884556 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3884556 |
From: <rl...@jb...> - 2005-07-12 16:37:28
|
As the build based upon the repository is now complete my next thoughts are on how is the best way to deploy this. A couple of points to consider are : 1) Maintaining backwards compatability 2) How maintenance will occur when changing the version of a dependency At one point it was discussed that a thirdparty folder that has been generated from the repository would be checked into cvs. This folder would then be aliased into the 4.0.x module. Does this still hold true? Whenever the build-thirdparty.xml file is modified a few events will need to transpire: 1) Regenerate the thirdparty directory 2) Check-in changes 3) Generate a new libraries.ent file 4) Check-in changes (provided that these items are being stored in cvs). Previously we had discussed storing the libraries.ent file as an artifact somewhere in the thirdparty directory. At some point (preferably build time) we must choose which version of the libraries.ent file to use; the one which contains the repository path structure, or the existing libraries.ent. This could be determined via a property passed in to the script. Thoughts? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3884555#3884555 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3884555 |
From: mholzner <nu...@jb...> - 2005-07-12 15:39:06
|
anonymous wrote : Is it, or will it be, possibile to define a renderer per window? So far I haven't thought about it. What is the use case? Why would you need to do this ? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3884547#3884547 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3884547 |
From: slonko <nu...@jb...> - 2005-07-12 15:09:38
|
Thanks, it's working now. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3884542#3884542 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3884542 |
From: michal.samak <nu...@jb...> - 2005-07-12 14:53:38
|
Hi guys, I'm involed in a project where session beans need to be exposed as web services (WS). The trouble is that the methods to be exposed as WS return complex object generated by JAXB compiler upon the XML schema. When I try with simple objects or JavaBeans everything works fine. But with JAXB objects I'm getting the following error: Caused by: java.io.IOException: java.io.IOException: No serializer found for class java.lang.Class in registry org.jboss.axis.encoding.TypeMappingImpl@fa7139 at org.jboss.axis.encoding.ser.BeanSerializer.serialize(BeanSerializer.java:362) at org.jboss.axis.encoding.SerializationContextImpl.serializeActual(SerializationContextImpl.java:1453) at org.jboss.axis.encoding.SerializationContextImpl.serialize(SerializationContextImpl.java:892) at org.jboss.axis.message.RPCParam.serialize(RPCParam.java:265) at org.jboss.axis.message.RPCElement.outputImpl(RPCElement.java:445) at org.jboss.axis.message.SOAPElementAxisImpl.output(SOAPElementAxisImpl.java:1449) at org.jboss.axis.message.SOAPBodyAxisImpl.outputImpl(SOAPBodyAxisImpl.java:157) at org.jboss.axis.message.SOAPEnvelopeAxisImpl.outputImpl(SOAPEnvelopeAxisImpl.java:588) at org.jboss.axis.message.SOAPElementAxisImpl.output(SOAPElementAxisImpl.java:1449) at org.jboss.axis.MessagePart.writeTo(MessagePart.java:299) All JAXB objects have one attribute named version which is of type java.lang.Class but even if I remove it the problem will remain. Do you have any idea what to do? I'm using JBoss 4.0.2, j2se1.4.2_08 and jwsdp 1.5. The webservices are declared as rpcliteral (or rpcencoded - the result is the same). Any help or hint is appreciated. Thanks in advance. Michal View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3884538#3884538 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3884538 |
From: <aco...@jb...> - 2005-07-12 14:48:12
|
Okay I agree, except for the performance testing. I think that performance requirements on individual units of code can also be useful. Meaning even if I'm running on my laptop, parsing mail headers ought not take more than a few MS right? The challenge is always the GC, but that can be handled via ant passing the right parms anyhow. I'm about to start work on the izpack stuff. I'd really appreciate if you keep watch and provide feedback and assistance to fascillitate its use. I'd like to avoid being the only maintainer of the descriptors (there will be a later post regarding these in general). View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3884536#3884536 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3884536 |
From: <sco...@jb...> - 2005-07-12 12:58:54
|
Both the xml and kernel tests are passing with xerces 2.7.0 using the SaxJBossXBParser implementation of the JBossXBParser so I am updating thirdparty to that version. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3884516#3884516 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3884516 |
From: <kab...@jb...> - 2005-07-12 10:56:38
|
That is not possible, pointcuts are static. However, you can intercept calls to Class.forName(), and use the dynamic per-instance api to add interceptors to the returned object. For this to work though, the returned objects need to have been prepared. http://docs.jboss.com/aop/1.3/aspect-framework/examples/dynamic-aop/dynamic.html http://docs.jboss.com/aop/1.3/aspect-framework/reference/en/html/dynamic.html View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3884500#3884500 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3884500 |
From: ravi_oops <nu...@jb...> - 2005-07-12 09:59:13
|
Hi, I am trying to integrate Eclipse3.0 with Jboss4.0.1-sp1 I have installed Eclipse 3.0 allready and according to the site that is specified http://docs.jboss.org/jbosside/install/build/en/html/installation.html I am trying to setup JBoss plugins. Every thing is set up fine but when I try to create a New Project. It gives a Option for Jboss-IDE. But when I click on J2EE 1.3 or J2EE1.4project and click next Eclipse gives a Error saying Plug-in org.jboss.ide.eclipse.jdt.j2ee.ui was unable to load class org.jboss.ide.eclipse.jdt.j2ee.ui.wizards.projects.J2EE14ProjectCreationWizard I checked in the plugin Directory it has the org.jboss.ide.eclipse.jdt.j2ee.jsp.ui_1.4.0 and also org.jboss.ide.eclipse.jdt.j2ee.jsp.ui_1.4.1.e30 Can any one tell me where I am goin wrong thanx ravi oops View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3884493#3884493 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3884493 |
From: mikezzz <nu...@jb...> - 2005-07-12 09:23:07
|
I think what would be sensible is make it possible (but not necessary) to run all of the tests* inside of the app server. Therefore it would be a subset of the tests that could be run outside of the app server. I have been looking at the tests that start their own instance of the MBean Server. I'm a little wary of these as a number of reasons. 1) The are far to complex to write >50% of the code is used to handle the setUp and tearDown methods (Most of this code disappears when running in the app server). 2) They rely to heavily of stubbed classes. In my experience stubbed classes simply hid problems until later on in the development process. Also it creates a lot of extra code to maintain. Its much easier to test against real instances when running in the app server. 3) They tend to be brittle, with all extra mbean management code, stubbed classes and our own depends-service.xml, breakages occur often when our code or JBoss changes. Am I willing to sacrifice an extra minute or 2 for the test suite to run, for simplicity, completeness and maintainablilty? Definitely. The JMXTestRunner does provide a mechanism to run test suite ad-hoc via the JMX Console (I generally run an app server consantly while developing). However I will make sure that the subset of tests that fall into category 1 can be run outside the app server. This can be achieved by using a fileset in the build.xml which contains the subset of Category 1 tests. I think also some of our code could be refactored to reduced dependencies. E.g. should the Mail class depend on a installed an configured SMTP protocol? *Performance test should generally be run seperately. The load testing client should also be on seperate box to more realistically similate load. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3884490#3884490 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3884490 |