jboss-dev-forums — The jboss development forum posts

[Jboss-dev-forums] [Design of JBoss Portal] - (Problem in the) New version of jboss portal

[lnhf <nu...@jb...>]

Hi all,
I have see the new version of jboss portal. I had the old version 2.0beta. So I have already the database. (but where is the setup.ddl file ? I haven't it.)
I just download jboss_portal_2.0_RC1-jboss_4.0.1sp1.zip and install it at the place of jboss4.0.0. 
I use SQL Server (so I have proceed to change, like 2.0beta).
I run jboss, but I have error(s) : 


  | DEBUG [org.jboss.portal.core.invocation.StrategyInterceptor] setting layout URI: /nodesk/index.jsp
  | DEBUG [org.jboss.portal.core.invocation.StrategyInterceptor] done analyzing layout strategy
  | ERROR [org.jboss.portal.server.servlet.CommandFilter] Exception in command invocation
  | javax.servlet.ServletException: org/apache/jsp/WEB_002dINF/jsp/user/login_jsp (Unsupported major.minor version 49.0)
  | 	at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:244)
  | 	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.portal.portlet.impl.PortletRequestDispatcherImpl.execute(PortletRequestDispatcherImpl.java:71)
  | 	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:324)
  | 	at org.jboss.portal.server.servlet.CommandFilter.doFilter(CommandFilter.java:54)
  | 	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.ApplicationDispatcher.invoke(ApplicationDispatcher.java:704)
  | 	at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:590)
  | 	at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:510)
  | 	at org.jboss.portal.portlet.impl.PortletRequestDispatcherImpl.include(PortletRequestDispatcherImpl.java:113)
  | 	at org.jboss.portal.core.portlet.user.UserPortlet.doView(UserPortlet.java:412)
  | 	at org.jboss.portlet.JBossPortlet.doDispatch(JBossPortlet.java:217)
  | 	at org.jboss.portlet.JBossPortlet.render(JBossPortlet.java:204)
  | 	at org.jboss.portlet.JBossPortlet.render(JBossPortlet.java:347)
  | 	at org.jboss.portal.portlet.invocation.DispatcherInterceptor.invokeRequest(DispatcherInterceptor.java:163)
  | 	at org.jboss.portal.portlet.invocation.DispatcherInterceptor.invoke(DispatcherInterceptor.java:195)
  | 	at org.jboss.portal.server.impl.invocation.InvocationImpl.invokeNext(InvocationImpl.java:213)
  | 	at org.jboss.portal.portlet.invocation.PreferencesInterceptor.invoke(PreferencesInterceptor.java:93)
  | 	at org.jboss.portal.server.impl.invocation.InvocationImpl.invokeNext(InvocationImpl.java:213)
  | 	at org.jboss.portal.server.invocation.component.ContextDispatcherInterceptor$InvokeNextCommand.execute(ContextDispatcherInterceptor.java:94)
  | 	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:324)
  | 	at org.jboss.portal.server.servlet.CommandServlet.doGet(CommandServlet.java:49)
  | 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:697)
  | 	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.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:704)
  | 	at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:552)
  | 	at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:510)
  | 	at org.jboss.portal.server.invocation.component.ContextDispatcherInterceptor.invoke(ContextDispatcherInterceptor.java:58)
  | 	at org.jboss.portal.server.impl.invocation.InvocationImpl.invokeNext(InvocationImpl.java:213)
  | 	at org.jboss.portal.core.invocation.AccessControlInterceptor.invoke(AccessControlInterceptor.java:125)
  | 	at org.jboss.portal.server.impl.invocation.InvocationImpl.invokeNext(InvocationImpl.java:213)
  | 	at org.jboss.portal.server.invocation.component.CacheInterceptor.invoke(CacheInterceptor.java:74)
  | 	at org.jboss.portal.server.impl.invocation.InvocationImpl.invokeNext(InvocationImpl.java:213)
  | 	at org.jboss.portal.server.impl.invocation.InvocationImpl.invokeNext(InvocationImpl.java:238)
  | 	at org.jboss.portal.server.Component.invoke(Component.java:173)
  | 	at org.jboss.portal.server.invocation.portal.MainDispatcherInterceptor.invoke(MainDispatcherInterceptor.java:93)
  | 	at org.jboss.portal.server.impl.invocation.InvocationImpl.invokeNext(InvocationImpl.java:213)
  | 	at org.jboss.portal.core.invocation.StrategyInterceptor.invoke(StrategyInterceptor.java:182)
  | 	at org.jboss.portal.server.impl.invocation.InvocationImpl.invokeNext(InvocationImpl.java:213)
  | 	at org.jboss.portal.core.invocation.ViewInterceptor.invoke(ViewInterceptor.java:118)
  | 	at org.jboss.portal.server.impl.invocation.InvocationImpl.invokeNext(InvocationImpl.java:213)
  | 	at org.jboss.portal.server.invocation.portal.TargetInterceptor.invoke(TargetInterceptor.java:153)
  | 	at org.jboss.portal.server.impl.invocation.InvocationImpl.invokeNext(InvocationImpl.java:213)
  | 	at org.jboss.portal.core.invocation.ContentTypeInterceptor.invoke(ContentTypeInterceptor.java:117)
  | 	at org.jboss.portal.server.impl.invocation.InvocationImpl.invokeNext(InvocationImpl.java:213)
  | 	at org.jboss.portal.core.invocation.UserContextInterceptor.invoke(UserContextInterceptor.java:90)
  | 	at org.jboss.portal.server.impl.invocation.InvocationImpl.invokeNext(InvocationImpl.java:213)
  | 	at org.jboss.portal.server.impl.invocation.InvocationImpl.invokeNext(InvocationImpl.java:238)
  | 	at org.jboss.portal.server.PortalServer.invoke(PortalServer.java:186)
  | 	at org.jboss.portal.server.servlet.AbstractMainServlet.invoke(AbstractMainServlet.java:78)
  | 	at org.jboss.portal.server.servlet.AbstractMainServlet.doGet(AbstractMainServlet.java:71)
  | 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:697)
  | 	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.portal.core.servlet.TransactionFilter$1.run(TransactionFilter.java:79)
  | 	at org.jboss.portal.common.transaction.Transactions.requiresNew(Transactions.java:149)
  | 	at org.jboss.portal.core.servlet.TransactionFilter.doFilter(TransactionFilter.java:75)
  | 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:186)
  | 	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:534)
  | ERROR [org.jboss.web.localhost.Engine] ApplicationDispatcher[/portal-core] Servlet.service() for servlet jsp threw exception
  | java.lang.UnsupportedClassVersionError: org/apache/jsp/WEB_002dINF/jsp/user/login_jsp (Unsupported major.minor version 49.0)
  | 	at java.lang.ClassLoader.defineClass0(Native Method)
  | 	at java.lang.ClassLoader.defineClass(ClassLoader.java:537)

Must I change database ? or have I forget anything ?

Thank you for your help.

lnhf

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877335#3877335

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877335

[Jboss-dev-forums] [Design of JBoss Portal] - Re: JBoss Portal 2.0 and Oracle ADF Faces

[bluca <nu...@jb...>]

thank you.
And what about JBoss portal and JSF.
How do you feel ?


View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877334#3877334

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877334

[Jboss-dev-forums] [Design of Mail Services] - Re: Integrating jASEN

[<aco...@jb...>]

ATM it should provided the original email was MIME.  IIRC, we do not convert messages to MIME if they were simple text.  Also you have to deal with bounce messages which are simple text (but if we generated the bounce message then no reason to check its spam nature).  I actually favor a internal routing envelope myself.

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877333#3877333

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877333

[Jboss-dev-forums] [Design of Mail Services] - Re: JBoss as web mail server

[<aco...@jb...>]

No we don't.  I'm not sure its useful anyhow.  Most spam I get says its from a valid domain.  Now it would be possible (theoretically) to use the header to check that the ip indeed belonged to that host but no way you're achieving #1 if you do that and I'm sure it would block certain types of legitimately relayed mail (internal corporate SMTP->ISP SMTP where the internal is not accessible from the outside).

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877332#3877332

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877332

[Jboss-dev-forums] [Design of JBoss Media (EMB)] - non-embedded media / MediaSegment

[-nick- <nu...@jb...>]

hi,

i'm currently trying to develop a small sample application with the media 
foundation beans/ enterprise media beans! however, i do have some 
difficulties understanding the assembleContent/disassembleContent methods
as well as the MediaSegment Class.

has anybody implemented a non-embedded media format yet with the
assembleContent/disassembleContent methods? 

i would really appreciate any kind of help or code examples!!!

nick

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877321#3877321

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877321

[Jboss-dev-forums] [Design of JBossXB] - Re: POJO Schema parsing

[<ale...@jb...>]

"ad...@jb..." wrote : Is it possible for the parser to understand this or is this just something that
  | isn't guaranteed to work with xml?
  | 
  |   | <map>
  |   |    <key/><value/>
  |   |    <key/><value/>
  |   |    <key/><value/>
  |   | </map>
  |   | 

So, there are several issues with maps:
1) representation of entries in XML
2) unmarshalling entries (representation of entries in Java)
3) configuration, e.g. with xsd annotations, etc

1) Representation in XML
Probably, the most natural one is to have an element that wraps key/value pair, e.g. that represents the entry. This is what you currently do.
I don't see a problem with having "complex" keys and values. A key element is unmarshalled (be it of a complex or a simple type) and used as the key, the same for the value element.

Another representation is actually your question. I don't have tests for this but it's possible as long as you can rely on the order of the elements in the sequence, i.e. after the key element we always have the corresponding value element. In XSD, when you define the type of the map, you have to use sequence compositor (other kinds of compositors are 'choice' and 'all'). If the compositor is 'all', the order of the elements in XML content is not guaranteed (SAX parser of course will still report elements in the order they appear in the XML content). This is important if we want to make sure that if an XML content is valid we can guarantee the unmarshalling result.
How to unmarshal this? Create an entry object when the key element starts, complete and add the entry to the map when the value element is parsed.

I was thinking about adding a convenient API for unmarshalling a sequence of elements (w/o a wrapper element) into one object but didn't want to complicate the API too early. I think, it'll be added in the future.

2) Unmarshalling of and Java representation of entries
In the approach we use currently, we create objects ahead, i.e. when an element starts we create an object and then add data to it when we parse the content of the element.
The disadvantage of this approach is that sometimes we have to create temporary container objects, like a map entry object (as you do) which we actually don't need or a container for constructor arguments for classes that don't have default no-arg constructors.
In general, there is no way you can avoid an 'entry' object in this approach.

A bit of theory... another approach would be to expose the stack of objects (which is present anyway) to unmarshalling handlers. And instead of requering an element handler to return an object from startElement (or whatever it's called), let the handler to push an object (or maybe even several objects into the stack). Attribute values, text content and child elements would also be pushed into the stack. In the endElement, the element handler would pop objects from the stack and do whatever is needed, i.e. pop key and value from the stack and add them to the map, pop ctor arguments and create an instance, etc.
I had one prototype of this approach but the API was a bit complex and error-prone. Though, maybe it was just a bad try.

3) configuration, xsd annotation or something else
I am also actually not sure atm how it would translate into xsd annotations. But I believe it's possible :)

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877311#3877311

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877311

[Jboss-dev-forums] [Design of AOP on JBoss (Aspects/JBoss)] - Re: ArrayIndexOutOfBoundsException during field interception

[<kab...@jb...>]

Hi,

I had a very brief look (using my own class) but could not reproduce the error. If you have the time, could you please put together a simple test case that reproduces the problem and send it to me?

Thanks

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877310#3877310

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877310

[Jboss-dev-forums] [Design of AOP on JBoss (Aspects/JBoss)] - Re: bugfix FieldAccessTransformer

[<kab...@jb...>]

Great,

I've added your fixes to cvs.

Thanks

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877306#3877306

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877306

[Jboss-dev-forums] [Design of AOP on JBoss (Aspects/JBoss)] - bugfix FieldAccessTransformer

[hengels <nu...@jb...>]

     [aopc] {    if (currentInterceptor < interceptors.length)    {       try         {          return interceptors[currentInterceptor++].invoke(this);       }        catch (Throwable t)        {           currentInterceptor--;           throw t;       }    }  typedTargetObject.bytBerKurzbezeichnung = ((Byte)value).byteValue() return null;}
  |      [aopc] java.lang.RuntimeException: failed to transform: wilken.basismodul.allgemein.StammdatenbezeichnungImpl
  |      [aopc]     at org.jboss.aop.instrument.Instrumentor.transform(Instrumentor.java:625)
  |      [aopc]     at org.jboss.aop.AspectManager.translate(AspectManager.java:572)
  |      [aopc]     at org.jboss.aop.AspectManager.transform(AspectManager.java:490)
  |      [aopc]     at org.jboss.aop.standalone.Compiler.compileFile(Compiler.java:258)
  |      [aopc]     at org.jboss.aop.standalone.Compiler.compile(Compiler.java:191)
  |      [aopc]     at org.jboss.aop.standalone.Compiler.main(Compiler.java:68)
  |      [aopc] Caused by: javassist.CannotCompileException: by javassist.CannotCompileException: [source error] ; is missing
  |      [aopc]     at org.jboss.aop.instrument.FieldAccessTransformer$OptimizedTransformer.buildOptimizedWriteWrapper(FieldAccessTransformer.java:442)
  |      [aopc]     at org.jboss.aop.instrument.FieldAccessTransformer$OptimizedTransformer.buildOptimizedWrappers(FieldAccessTransformer.java:346)
  |      [aopc]     at org.jboss.aop.instrument.FieldAccessTransformer$OptimizedTransformer.buildFieldWrappers(FieldAccessTransformer.java:232)
  |      [aopc]     at org.jboss.aop.instrument.FieldAccessTransformer.buildFieldWrappers(FieldAccessTransformer.java:65)
  |      [aopc]     at org.jboss.aop.instrument.Instrumentor.transform(Instrumentor.java:591)
  |      [aopc]     ... 5 more
  | 

can be fixed by simply adding a semicolon to line 591, method castInvocationValueToTypeString of class FieldAccessTransformer:

               cast = "((Byte)value).byteValue();";
  | 

release 1.1.2

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877304#3877304

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877304

[Jboss-dev-forums] [Design of JBossXB] - Re: POJO Schema parsing

[<ale...@jb...>]

"ad...@jb..." wrote : It looks like the new parsing is going to cope with everything I throw at it
  | for the pojo parsing. Well done Alex.

Glad to hear it works for you :)
I am still not satisfied with the API though. And, frankly, am still also experimenting with other prototypes of the same style trying to come up with a more elegant programming model.
Sorry, got hooked and just can't stop now :)

"ad...@jb..." wrote : The outstanding issues are:
  | 1) Using schema annotations to define the parsing
  | 2) The ANY parsing
  | 3) Making the map definition less verbose.

1) I think, annotations will be the next step (will need to patch xerces.2.6 for this, 2.7 is going to be released about June 24).
2) I'll probably write some kind of spec for this before coding so we can discuss it in details.
3) is being discussed in this thread.

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877300#3877300

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877300

[Jboss-dev-forums] [Design of JBoss Portal] - Re: JBoss Portal and MyFaces work a dream

[gavinc <nu...@jb...>]

I tried the filter dispatcher tip you mentioned Stan but unfortunately it didn't work as expected. The filter does now get called but it obviously does something to the request that MyFaces doesn't like as all I get on my page is the word "null"!!

I have also remembered another minor issue we ran into with the MyFaces/Portal integration. Before switching over we were able to re-deploy our portlet application but we now get an error. When I turned on debugging I also noticed that MyFaces seems to get initialised twice, so I don't know if this has anything to do with it?

It seems you have to have the context listener entry in your web.xml otherwise you get errors when starting the app but when the MyFacesGenericPortlet initialises it also configures MyFaces. It is at this point in the re-deploy that we get the stack trace below:

java.lang.IllegalArgumentException: Class org.apache.myfaces.application.ActionListenerImpl is no javax.faces.event.ActionListener
        at org.apache.myfaces.config.FacesConfigurator.getApplicationObject(FacesConfigurator.java:560)
        at org.apache.myfaces.config.FacesConfigurator.configureApplication(FacesConfigurator.java:464)
        at org.apache.myfaces.config.FacesConfigurator.configure(FacesConfigurator.java:215)
        at org.apache.myfaces.portlet.MyFacesGenericPortlet.initMyFaces(MyFacesGenericPortlet.java:177)
        at org.apache.myfaces.portlet.MyFacesGenericPortlet.init(MyFacesGenericPortlet.java:120)
        at javax.portlet.GenericPortlet.init(GenericPortlet.java:342)
        at org.jboss.portal.portlet.PortletContainer.start(PortletContainer.java:129)


One final question, do you plan on putting any error handling mechanism into MyFacesGenericPortlet so that if an error gets thrown we can configure a JSF page to get displayed? (rather than the portlet showing a large stack trace)



View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877298#3877298

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877298

[Jboss-dev-forums] [Design of AOP on JBoss (Aspects/JBoss)] - Re: Retain ProtectionDomain for instrumented classes

[twundke <nu...@jb...>]

Sorry I wasn't clearer in my original post. It's been a while since I looked at this issue.

My particular problem is that the generated field wrapper inner classes don't get assigned the correct protection domain. Here's a stack trace that shows the problem occuring.


  | 	  getDefaultDomain():1583, ClassLoader.java
  | 	  preDefineClass():483, ClassLoader.java
  | 	  defineClass():614, ClassLoader.java
  | 	  defineClass():465, ClassLoader.java
  | 	  invoke0():-1, NativeMethodAccessorImpl.java
  | 	  invoke():39, NativeMethodAccessorImpl.java
  | 	  invoke():25, DelegatingMethodAccessorImpl.java
  | 	  invoke():585, Method.java
  | 	  toClass():52, StandaloneClassPool.java
  | 	  toClass():962, CtClass.java
  | 	  compileOrLoadClass():119, TransformerCommon.java
  | 	  createOptimizedInvocationClass():572, FieldAccessTransformer.java
  | 	  buildOptimizedReadWrapper():358, FieldAccessTransformer.java
  | 	  buildOptimizedWrappers():342, FieldAccessTransformer.java
  | 	  buildFieldWrappers():232, FieldAccessTransformer.java
  | 	  buildFieldWrappers():65, FieldAccessTransformer.java
  | 	  transform():592, Instrumentor.java
  | 	  translate():572, AspectManager.java
  | 	  transform():490, AspectManager.java
  | 	  aspectTransform():100, AopAgent.java
  | 	  transform():141, AopAgent.java
  | 	  transform():122, TransformerManager.java
  | 	  transform():155, InstrumentationImpl.java
  | 	  defineClass1():-1, ClassLoader.java
  | 	  defineClass():620, ClassLoader.java
  | 	  defineClass():320, BaseURLClassLoader.java
  | 	  access$000():38, BaseURLClassLoader.java
  | 	  run():108, BaseURLClassLoader.java
  | 	  run():98, BaseURLClassLoader.java
  | 	  doPrivileged():-1, AccessController.java
  | 	  findClass():96, BaseURLClassLoader.java
  | 	  findClassInternal():168, BaseClassLoader.java
  | 	  findClassInternal():146, BaseClassLoader.java
  | 	  findClassInternal():49, FrameworkClassLoader.java
  | 	  loadClass():280, BaseClassLoader.java
  | 	  loadClass():251, ClassLoader.java
  | 	  loadClassInternal():319, ClassLoader.java
  | 	  initialiseDomains():117, DomainManagerImpl.java
  | 	  <init>():78, DomainManagerImpl.java
  | 	  start():153, FrameworkController.java
  | 	  invoke0():-1, NativeMethodAccessorImpl.java
  | 	  invoke():39, NativeMethodAccessorImpl.java
  | 	  invoke():25, DelegatingMethodAccessorImpl.java
  | 	  invoke():585, Method.java
  | 	  initialiseFramework():366, FrameworkLoader.java
  | 	  main():463, FrameworkLoader.java
  | 

The toClass method of StandaloneClassPool does the following:

  |          Class cl = Class.forName("java.lang.ClassLoader");
  |          java.lang.reflect.Method method
  |                  = cl.getDeclaredMethod("defineClass",
  |                          new Class[]{String.class, byte[].class,
  |                                      int.class, int.class});
  | 

My classloader doesn't get a chance to define the class, causing the field wrappers to be assigned a default protection domain.

So, what's actually needed is for the class pool to use the correct classloader when calling defineClass.

Hope that helps.

Tim.

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877296#3877296

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877296

[Jboss-dev-forums] [Design of JMX on JBoss (JBoss/JMX)] - Re: Setting the thread context class loader on mbean op disp

[<ad...@jb...>]

"ben...@jb..." wrote : 
  | But you maybe right. Solution is then I will need to set tcl before calling getPojo regardless what. 
  | 
  | Let me try.
  | 

No, because invoking the proxy will change the classloader.

Your fundamental problem (as I understand your description in JBCACHE-151)
is that the code that does the serialization/deserialization
doesn't understand classloader context. That is why you need the MarshalledValue.

Class.forName(String) is going to use the classloader that loads your jboss cache class
regardless of what JMX does.

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877271#3877271

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877271

[Jboss-dev-forums] [Design of JMX on JBoss (JBoss/JMX)] - Re: Setting the thread context class loader on mbean op disp

[<ben...@jb...>]

Yeah, you were looking at the wrong code. That marshalling/unmarshalling code works. 

This is the code that failed:

  |    public Object getPojo(String sessionId, String key)
  |    {
  |       String realId = stripJvmRoute(sessionId);
  |       if(log_.isDebugEnabled())
  |       {
  |          log_.debug("getPojo(): session id: " +sessionId + " key: " +key);
  |       }
  |       // Construct the fqn.
  |       Fqn fqn = getFieldFqn(realId, key);
  |       try {
  |          return proxy_.getObject(fqn);
  |       } catch (CacheException e) {
  |          e.printStackTrace();
  |          throw new RuntimeException("JBossCacheService: exception occurred in cache getPojo ... ", e);
  |       }
  |    }
  | 

And this code will call JBossCacheAop (you will have to check out JBossCache module though. :-)

But you maybe right. Solution is then I will need to set tcl before calling getPojo regardless what. 

Let me try.


View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877269#3877269

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877269

[Jboss-dev-forums] [Design of the JBoss Web Container] - JSF Configuration

[DavidFinnegan <nu...@jb...>]

Is there any documentation of myfaces as it relates to JSF and Tomcat 5.5 on 4.0.2 AS.

1. What the directory structure should look like for all jars, tlds, xml config files, build classpaths, and related files such as org.apache listeners.

2. Whether to deploy a filename.war under the all:default/deploy directory or an exploded war such as somedirectoryname.war under the jbossweb-tomcat5.5.sar, as I have tried both.

3. A simple example to test out configurations.

I have setup in eclipse a system library of the core files, created also libs dir in my project folder, under jbossweb-tomcat5.5.sar and put the listener under this directory also. Here is my build output from ant:

META-INF/
META-INF/MANIFEST.MF
WEB-INF/
WEB-INF/classes/
WEB-INF/classes/com/
WEB-INF/classes/com/UserBean.class
WEB-INF/faces-config.xml
WEB-INF/lib/
WEB-INF/lib/commons-beanutils.jar
WEB-INF/lib/commons-collections.jar
WEB-INF/lib/commons-digester.jar
WEB-INF/lib/commons-logging.jar
WEB-INF/lib/jsf-api.jar
WEB-INF/lib/jsf-impl.jar
WEB-INF/lib/servlet-api.jar
WEB-INF/web.xml
faces-config.xml
index.faces
index.html
index.jsp
web.xml
welcome.jsp


Any thoughts would be appreciated.

Thanks

DF



View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877268#3877268

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877268

[Jboss-dev-forums] [Design of JMX on JBoss (JBoss/JMX)] - Re: Setting the thread context class loader on mbean op disp

[<ad...@jb...>]

Please fix the e.printStackTrace()
while you are in this code.

And the double logging abomination.


  |          String str = cacheServiceName_ + " service to Tomcat clustering not found";
  |          log_.error(str);
  |          throw new ClusteringNotSupportedException(str);
  | 

trace and throw - yes
error and throw just makes your eyes bleed as the console flashes past
with the all the duplicate logging. :-)

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877267#3877267

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877267

[Jboss-dev-forums] [Design of JMX on JBoss (JBoss/JMX)] - Re: Setting the thread context class loader on mbean op disp

[<ad...@jb...>]

I'm obviously looking at the wrong code since it is already setting
the correct TCL:

JBossCacheService

  |    private Object getUnMarshalledValue(Object mv)
  |    {
  |       if (mv == null) return null;
  |       // Swap in/out the tcl for this web app. Needed only for un marshalling.
  |       ClassLoader prevTCL = Thread.currentThread().getContextClassLoader();
  |       Thread.currentThread().setContextClassLoader(tcl_);
  |       try
  |       {
  |          return ((MarshalledValue) mv).get();
  |       }
  |       catch (IOException e)
  |       {
  |          e.printStackTrace();
  |          return null;
  |       }
  |       catch (ClassNotFoundException e)
  |       {
  |          e.printStackTrace();
  |          return null;
  |       }
  |       finally
  |       {
  |          Thread.currentThread().setContextClassLoader(prevTCL);
  |       }
  |    }
  | 

where tcl_ is coming from the Tomcat config.

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877266#3877266

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877266

[Jboss-dev-forums] [Design of JMX on JBoss (JBoss/JMX)] - Re: Setting the thread context class loader on mbean op disp

[<ben...@jb...>]

I have created a Jira for future reference:
http://jira.jboss.com/jira/browse/JBAS-1803

Meanwhile, I will try to get around that problem by using a MarshalledValue wrapper. It will have performance impact but it should work for now.

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877264#3877264

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877264

[Jboss-dev-forums] [Design of JBossXB] - Re: POJO Schema parsing

[<sco...@jb...>]

For that usecase I would argue that there should be a properties mapping:


  | <properties>
  |    <entry key="key1">value1</entry>
  |    <entry key="key2">value2</entry>
  | </properties>
  | 

because this is a universal construct that I could define a reusable xsd fragment for the content model and annotation for the binding.



View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877257#3877257

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877257

[Jboss-dev-forums] [Design of JBossXB] - Re: POJO Schema parsing

[<ad...@jb...>]

The issue is the verbosity, not just the parsing.

Perhaps I could support both types of map descriptions?

With the short form probably being used the most often?

  | <entry key="AKEY">AVALUE</entry>
  | 

Essentially, all I'm doing is creating a temporary "entry"

  | entry.key = new StringValueMetaData("AKEY");
  | entry.value = new StringValueMetaData("AVALUE");
  | 
which is then used at the end of element to do

  | mapMetadata.put(entry.key, entry.value)
  | 

I'm not sure how this would tranlate to schema annotations?
I'll wait to see what Alex says, before doing any more on this.

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877253#3877253

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877253

[Jboss-dev-forums] [Design of JBossXB] - Re: POJO Schema parsing

[<sco...@jb...>]

I think incorporating the key into the entry as an attribute is too limiting. In terms of the difference between:


  | <map>
  |     <entry>
  |          <key><set><value>1</set></key>
  |          <value>collection><value>2</value></collection></value>
  |     </entry>
  | </map>
  | 
and:

  | <map>
  |       <key><set><value>1</set></key>
  |       <value>collection><value>2</value></collection></value>
  | </map>
  | 

I don't think its an issue of the parser not handling it, but rather having to introduce an uneccessary compilication in the handling of the parser stack state to effectively combine the key and value elements into a composite context at the object factory layer. Alexey could better speak to whether this is an actual complication in the current object factory though. However, since the entry element really does not translate to a single object as far as the java.util.Map api is concerned, the pair does have to be dealt with, and I don't see that its much easier to keep track of this by adding an entry element since the pair container can just as easily be created at the start of the key element as a containing entry element.

I browsed through the jaxb2.0 spec again, and they don't support map type of collections. Only arrays and list type of collections are supported so this is a construct that won't be supported other than by proprietary bindings.


View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877250#3877250

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877250

[Jboss-dev-forums] [Design of JBoss Portal] - Re: Portlet intercommunication

[sven.schulz <nu...@jb...>]

Hi fernir,

is there a spec. draft available already. Where can I find it? Hope this spec. is not to complex, since implementing a complex system would be not that beneficial in the face of an emerging JSR-168 successor.

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877245#3877245

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877245

[Jboss-dev-forums] [Design of JBossXB] - Re: POJO Schema parsing

[<ad...@jb...>]

Actually, it looks like I spoke too soon.
e.g. What is a good format for defining a map that has non-trivial
objects in the key as well as the value.


  | <map>
  |    <entry>
  |         <key><set><value>1</set></key>
  |         <value>collection><value>2</value></collection></value>
  |    </entry>
  | </map>
  | 

Perhaps this is such a stupid use case we shouldn't support it, and just
incorporate the key into the entry
i.e. only support trivial keys:


  | <map>
  |    <entry key="1" class="java.lang.Integer">
  |        <collection><value>2</value></collection>
  |    </entry>
  | </map>
  | 

I think this would also solves the parsing problem, mentioned above.

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877241#3877241

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877241

[Jboss-dev-forums] [Design of JBoss Portal] - Re: Portlet intercommunication

[fernir <nu...@jb...>]

There is a another specification that defines a contract between portal consumer and portlet consumer for remote portlets utilizing soap - WSRP (http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsrp). Second version of this specification that have been discussed now introduces event handling mechanism that will allow consumer to distribute events to any portlet and any portlet to generate events as a result of perform action or event distribution call. My suggestion would be to use this specification as a guide line for even support architecture.

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877240#3877240

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877240

[Jboss-dev-forums] [Design of JBossXB] - Re: POJO Schema parsing

[<ad...@jb...>]

I'd appreciate any insight on the Map/Entry parsing:
http://jira.jboss.com/jira/browse/JBMICROCONT-36

Is it possible for the parser to understand this or is this just something that
isn't guaranteed to work with xml?

  | <map>
  |    <key/><value/>
  |    <key/><value/>
  |    <key/><value/>
  | </map>
  | 

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877238#3877238

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877238