Please Advise: jst server adapters in exadel code
by Rob Stryker
The following projects exist in our codebase. They all use the Generic
Server adapter.
org.jboss.tools.jst.server.jboss
org.jboss.tools.jst.server.jetty
org.jboss.tools.jst.server.jrun
org.jboss.tools.jst.server.resin
At the very least, I recommend that the jboss adapter be removed from
our SVN.
I can see the benefit of the other three in our tools, to remain open to
all others
who may want to use our tools. This is fine for me, and you'll hear no
objections.
The only suggestion I'd have is to unify all of them into one plugin in
the "AS" module,
rather than keep them bundled in the "jst" module bundled with jst.web
and jst.jsp.
I also suggest that org.jboss.tools.jst.firstrun move to the "as" module
as well,
though I'm not quite as sure about this.
Finally, if no one else has any problem with this, I also think moving the
"start server" / "stop server" tool button into the as.ui plugin...
though the
effects of that will need to be looked into since it's mixed in with the
org.jboss.tools.jst.web plugin.
Thoughts and comments from all are welcome.
- Rob Stryker
18 years, 1 month
QA Daily report 12 May 2008
by Aliaksey Nis
Hello Denis,
This is Daily QA report for 12 May 2008.
Tasks performed:
1. Free testing of JBDS 1.1.0.CR1 build.
2. VPE testing.
3. Issues verification.
--
Best regards,
Aliaksey mailto:anis@exadel.com
18 years, 1 month
Seam EAR project
by Snjezana Peco
I have tested JBDS on Windows and can reproduce 2 issues regarding
creating and publishing a Seam application.
Not sure if they are known issues, but I haven't seen any jira issues
related to them.
In order to reproduce the issues just do the following:
- start JBDS
- remove all deployed projects in the JBoss Server view
- ensure that no one project exists in the deploy directory on the JBoss
Server
- create a Seam EAR project named "test"
Problem 1:
The test and test-ejb projects aren't builded correctly (there are errors).
- rebuild all the projects
- publish
- start the JBoss server
The test-ear project is builded and deployed correctly
- delete all the projects
You will get the error "test-ejb does not exist", but the projects are
removed correctly in the Eclipse workspace
- create the test project again
You will face the same problem again
- rebuild all the projects
- publish
The problem is solved.
Problem 2:
- open a login page and try to log in
You will get the attached exception
The project isn't deployed correctly. It is possible that this problem
is caused by a Windows locking problem. If you stop the server before
removing the project, the problem won't happen.
I assume that JBoss Tools tries to undeploy the project and succeeds
only partially.
In order to solve the issue do the following:
- stop the server
- call Full Publish
- start the server
Snjeza
javax.faces.el.EvaluationException: javax.el.PropertyNotFoundException: Target Unreachable, identifier 'authenticator' resolved to null
at com.sun.faces.application.MethodBindingMethodExpressionAdapter.invoke(MethodBindingMethodExpressionAdapter.java:95)
at org.jboss.seam.actionparam.ActionParamBindingHelper.invokeTheExpression(ActionParamBindingHelper.java:58)
at org.jboss.seam.actionparam.ActionParamMethodBinding.invoke(ActionParamMethodBinding.java:75)
at org.jboss.seam.core.Expressions$2.invoke(Expressions.java:148)
at org.jboss.seam.security.jaas.SeamLoginModule.login(SeamLoginModule.java:104)
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:597)
at javax.security.auth.login.LoginContext.invoke(LoginContext.java:769)
at javax.security.auth.login.LoginContext.access$000(LoginContext.java:186)
at javax.security.auth.login.LoginContext$5.run(LoginContext.java:706)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.login.LoginContext.invokeCreatorPriv(LoginContext.java:703)
at javax.security.auth.login.LoginContext.login(LoginContext.java:575)
at org.jboss.seam.security.Identity.authenticate(Identity.java:247)
at org.jboss.seam.security.Identity.authenticate(Identity.java:240)
at org.jboss.seam.security.Identity.login(Identity.java:170)
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:597)
at com.sun.el.parser.AstValue.invoke(AstValue.java:174)
at com.sun.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:286)
at com.sun.facelets.el.TagMethodExpression.invoke(TagMethodExpression.java:68)
at javax.faces.component.MethodBindingMethodExpressionAdapter.invoke(MethodBindingMethodExpressionAdapter.java:88)
at com.sun.faces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:102)
at javax.faces.component.UICommand.broadcast(UICommand.java:387)
at org.ajax4jsf.framework.ajax.AjaxViewRoot.processEvents(AjaxViewRoot.java:180)
at org.ajax4jsf.framework.ajax.AjaxViewRoot.broadcastEvents(AjaxViewRoot.java:158)
at org.ajax4jsf.framework.ajax.AjaxViewRoot.processApplication(AjaxViewRoot.java:346)
at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:82)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:100)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:265)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.jboss.seam.web.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:63)
at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:57)
at org.jboss.seam.web.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:49)
at org.jboss.seam.debug.hot.HotDeployFilter.doFilter(HotDeployFilter.java:60)
at org.jboss.seam.web.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:49)
at org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:45)
at org.jboss.seam.web.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:49)
at org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java:79)
at org.jboss.seam.web.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:49)
at org.jboss.seam.web.SeamFilter.doFilter(SeamFilter.java:84)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.ajax4jsf.framework.ajax.xmlfilter.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:127)
at org.ajax4jsf.framework.ajax.xmlfilter.BaseFilter.doFilter(BaseFilter.java:277)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:179)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:433)
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:241)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:580)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Thread.java:619)
Caused by: javax.el.PropertyNotFoundException: Target Unreachable, identifier 'authenticator' resolved to null
at org.apache.el.parser.AstValue.getTarget(AstValue.java:46)
at org.apache.el.parser.AstValue.invoke(AstValue.java:127)
at org.apache.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:276)
at com.sun.faces.application.MethodBindingMethodExpressionAdapter.invoke(MethodBindingMethodExpressionAdapter.java:88)
... 69 more
18 years, 1 month
Used ganymede for a week...
by Max Rydahl Andersen
228887 nor P3 Wind pde-ui-inbox(a)eclipse.org NEW Incorrect/incomplete error in problem view: "Plug-ins declaring
extensions or extension points must set the singleton directive to true"
231174 nor P3 Wind jdt-ui-inbox(a)eclipse.org NEW Excessive amount of validation monitors running
231249 nor P3 Wind wst.xml-inbox(a)eclipse.org NEW The content type with id "org.eclipse.wst.javascript.core.javascriptsource" specified in the extension point does not exist.
231250 nor P3 Wind jdt-debug-inbox(a)eclipse.org NEW java.util.EmptyStackException when evaluating .length on arrays
231257 cri P3 Wind wst.javascript-inbox@eclips... NEW Project modifications should be in the Project menu not the Context menu
231258 nor P3 Wind dali.general-inbox(a)eclipse.org NEW bug 231257 is also for JPA
231264 cri P3 Wind platform-ide-inbox(a)eclipse.org NEW Import existing projects hides projects
That is one bug found a day....even with 2 patches ;)
I do not hope this is a sign of the qualify of Ganymede in general - but I hope you guys also opens issues against bugs.eclipse.org if you find something broken/regressed....and if possibly with a patch.
Only way we can make a difference and show we care ;)
p.s. if you create a bug please add me: max.andersen(a)jboss.com in cc.
/max
18 years, 1 month
Legacy projects to be removed
by Rob Stryker
Legacy projects in our svn are going to be removed from trunk. They will
still be accessible in old release branches, however they are no longer
relevant to our development environment.
Specifically:
org.jboss.ide.eclipse.ejb3.*
org.jboss.ide.eclipse.jdt.aop.*
org.jboss.ide.eclipse.jdt.*
org.jboss.ide.eclipse.xdoclet.*
and others.
With the last release (mostly) out the door, it's time to start thinking
about forward development
and how we wish to keep our svn organized and clean. As we're switching
to eclipse 3.4,
and these projects are no longer maintained (and no longer compile),
they are good candidates for removal.
If at any point a patch against one of the recent release streams is
provided which brings these projects
into proper order and / or we find someone willing to maintain them, we
may merge them back in.
However, absent a maintainer, this is the proper move right now.
- Rob Stryker
18 years, 1 month
Re: Richfaces 3.2 ?
by Max Rydahl Andersen
Thanks for that info!
Alexey - there we have our test ;)
/max
> RichFaces 3.2.1.CR4 is going to be released this Sunday. So, you can start
> with it.
> If you need to start early, you can use any SNAPSHOT (nightly build) that
> released after 05/07/2008
>
> ----- Original Message -----
> From: "Max Rydahl Andersen" <max.andersen(a)redhat.com>
> To: "Sergey Smirnov" <sim(a)exadel.com>; "Alexey Kazakov"
> <akazakov(a)exadel.com>
> Cc: <jbosstools-dev(a)lists.jboss.org>; "Sergey Vasilyev"
> <svasilyev(a)exadel.com>; "Nikolay Belaevski" <nbelaevski(a)exadel.com>;
> "Alexander Smirnov" <asmirnov(a)exadel.com>
> Sent: Thursday, May 08, 2008 12:46 AM
> Subject: Re: Richfaces 3.2 ?
>
>
>>> RichFaces 3.2.1 is expected at the middle of May.
>>
>> cool - any chance you could let us know when you have a build with the
>> updated TLD's
>> so we could start integrating ASAP ?
>>
>> /max
>>
>>> ----- Original Message -----
>>> From: "Max Rydahl Andersen" <max.andersen(a)redhat.com>
>>> To: "Sergey Smirnov" <sim(a)exadel.com>; "Alexey Kazakov"
>>> <akazakov(a)exadel.com>
>>> Cc: <jbosstools-dev(a)lists.jboss.org>; "Sergey Vasilyev"
>>> <svasilyev(a)exadel.com>; "Nikolay Belaevski" <nbelaevski(a)exadel.com>;
>>> "Alexander Smirnov" <asmirnov(a)exadel.com>
>>> Sent: Wednesday, May 07, 2008 1:11 PM
>>> Subject: Re: Richfaces 3.2 ?
>>>
>>>
>>>>> We have never been change this number inside tld. It was 1.2 from the
>>>>> very
>>>>> first version. Mainly, because it does not make any since for run-time.
>>>>
>>>> Any tools and introspection tool would like to have it ;)
>>>>
>>>>> We
>>>>> store the true version in the manifest.mf located close to tlds files
>>>>> inside
>>>>> the META-INF instead.
>>>>> Actually, the standard limits the content of this tag. It must only
>>>>> numbers
>>>>> divided by up to 3 dots. So, we cannot put the exact version there like
>>>>> 3.2.0.GA or 3.2.0.SP1
>>>>
>>>> Just having the 3.2.0 would be sufficient for us since what comes after
>>>> the 4th dot should
>>>> be irelevant.
>>>>
>>>>> So, starting with RichFaces 3.2.1, we will turn CDK generator to
>>>>> generate
>>>>> three number divided by dots. It is not ideal, but close to.
>>>>
>>>> Its way better ;)
>>>>
>>>> When is 3.2.1 expected ?
>>>>
>>>>> In general, we can enhance CDK to generate not only TLD, but the
>>>>> meta-data
>>>>> for code extended assist. In this way, JBDS just needs to take this
>>>>> meta-file from the jar file instead of the place it takes now. It will
>>>>> help
>>>>> to migrate from version to version more smoothly and without extra work
>>>>> from
>>>>> the JBDS team.
>>>>
>>>> sounds like something we should investigate and do it in a way other
>>>> lib's
>>>> could use too.
>>>>
>>>> Kazakov - comments ?
>>>>
>>>> /max
>>>>
>>>>>
>>>>> I told with Alexey about this feature, but looks like this topic was
>>>>> just
>>>>> forgotten between the other more actual themes on that moment.
>>>>>
>>>>> ----- Original Message -----
>>>>> From: "Max Rydahl Andersen" <max.andersen(a)redhat.com>
>>>>> To: "Alexey Kazakov" <akazakov(a)exadel.com>
>>>>> Cc: <jbosstools-dev(a)lists.jboss.org>; "Sergey Vasilyev"
>>>>> <svasilyev(a)exadel.com>; "Sergey Smirnov" <sim(a)exadel.com>
>>>>> Sent: Wednesday, May 07, 2008 10:25 AM
>>>>> Subject: Re: Richfaces 3.2 ?
>>>>>
>>>>>
>>>>>>>> How long time would it take to add code completion support for RF
>>>>>>>> 3.2
>>>>>>>> ?
>>>>>>>>
>>>>>>> If we want to have RF 3.1.x by default (if we can't recognize the
>>>>>>> version of lib) then there will be a problem.
>>>>>>
>>>>>> But isn't the schemas distinct enough to always recognize the correct
>>>>>> version ?
>>>>>>
>>>>>> Note: if we can't recognize the version i'm probably fine by falling
>>>>>> back
>>>>>> to 3.2 by default.
>>>>>> btw. why is hard to set a specific version as the default ? Is it
>>>>>> hardcoded to take the latest version as default or ?
>>>>>>
>>>>>>> Richaces TLD version tag has not been updated since 1.2.
>>>>>>> So we are not able to tell one from the other.
>>>>>>
>>>>>> Are you telling me the richfaces team does not update their TLD's ?
>>>>>> I thought the CDK where supposed to make that "easy" ?
>>>>>>
>>>>>> I've cc'ed in Sergey S. to get his opinion on how we should go about
>>>>>> supporting
>>>>>> updates to richfaces if the libraries does not maintain their schema
>>>>>> version id's..?
>>>>>>
>>>>>>> It would take about one day to provide code completion for RF 3.2 but
>>>>>>> only default lib will work.
>>>>>>
>>>>>> ?
>>>>>>
>>>>>> /max
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>>
>
>
18 years, 1 month
Merging ganymede to trunk
by Max Rydahl Andersen
Hi,
I'll be merging the Ganymede branch to trunk over the next hour or so.
This means that when i'm done trunk is targeted for Ganymede and requires Eclipse 3.4M7 to develop against.
The 2.1.x branch will require Eclipse 3.3.2 - please beaware of that ;)
I'll be back when its done.
/max
18 years, 1 month
