Re: [jbosstools-dev] Next-generation VPE - Visual Page Viewer (VPV)
by Yahor Radtsevich
On Nov 21, 2012 9:25 AM, "Max Rydahl Andersen" <max.andersen(a)redhat.com>
wrote:
>
> > we've seen a few issues with the browsersim not working all smooth with
WebKit, but I guess for VPV this is less of a concern since we will simply
just
> > be using whatever built-into-eclipse browser is enabled by the user on
his platform, correct?
> > Yeah, it will use any browser. But of course, each browser, has its own
features/bugs which should be taken into account when creating the viewer.
>
> I guess those changes will actually leak into the various templates ?
i.e. the code would have to do "if browser=ie do X else do Y" ?
I hope none or only several of them will be affected, like rich:calendar,
which is very complicated and really 'rich'.
>
> > > If it is a rewrite we should make sure to move everything that is not
public api into internal packages.
> > > Will do it.
> >
> > Would also be good to make an effort on making the API to add support
for other libraries more approachable than previous VPE.
> > i.e. documented API's, example of how to do it etc.
> > Agree. We could also make creation of templates more approachable by
creating a simpler templating system. Now in VPE only Java and XML tamples
are allowed. But we could allow also something like javascript
micro-templating.
>
> interesting idea.
>
> > > How is that handled?
> > > One http server for one eclipse instance. Pages on the server will be
available under paths like localhost:xxxx/project/pathtopage/page.jsp. We
could also dispose the server when no VPE editor is opened.
> >
> > How about absolute relative paths like "/images/funky.png" - I guess
that will be handled the same way as before where the href's are rewritten
to have a proper "root" ?
>
> > Good question. I just forget about this root-relative case.
> > It looks like one server per viewer or at least one server per
workspace is needed to handle it. I assume, that our users may have several
editors opened, so one server with changing root directory is not an option.
> > Obvious drawbacks of multiple servers are:
> > - we have to manage their creation/disposal
> > - these servers will consume more resources (not much, but at least a
port and a connection-waiting thread per each)
> > - pages from different projects will not be able communicate with each
other, because of same-origin policy. (Anyway, now I am not planning that
they will communicate even on one server per workspace.)
> > These seem to be not very big problems, probably it is worth it to
create a server per editor, which should be pretty easy to maintain.
>
> well multiple open ports for an app is not exactly awesome.
>
> Especially not if these threads aren't fast to shutdown (i.e. instantly)
>
> How about multiplexing these somehow - can you control part of the
useragent or other parts of the browser which you could use in the request
to make the server respond differently ?
>
> i.e. useragent set to "VPV-root: xxxx/project/" and let the server
respond accordingly?
>
> Someway to expose the properties the visual page editor already have in
context of "root" and "absolute root" settings already.
I wouldn't like to change the user agent, because client logic may depend
on it. Changing/adding of another request headers won't work in WebKit.
Today we found that the following approach may work.
If we set URL as http://localhost:1234/index.jsp?root=xxxx/project/, then
all linked resources will be requested with the 'Referer' header set to
this URL. This header may be used on the server to return right resources.
What I like in this approach is that it will also work for any browser, a
SWT embedded browser or a stand alone browser.
Redirects/clicks from one page to another should be handled separately, but
it is possible in SWT to do URL rewrite before the page requests are sent.
Another drawback we found is that html frames won't work this way.
>
> > btw. who's github branch are you doing this work in ? Would be nice to
take a look and try run it from time to time.
> > Now it scaterred locally and in old svn workspaces. I will create a vpv
branch in github/yradtsevich/jbosstools-vpe.
>
> okey - let us know when something to look at.
>
> /max
13 years, 3 months
Re: [jbosstools-dev] Integration tests on coretests update site?
by Max Rydahl Andersen
cc'ing jbosstools-dev:
> Probably I missed discussion about this I'm sorry.
nope - it haven't really been discussed.
> What do you think about adding JBT integration tests (SWTBot tests) to JBT coretest ( http://download.jboss.org/jbosstools/updates/nightly/coretests) update site?
If the integration-tests will work on the core target platform then sure.
But afaik you still use a mix of reddeer and soa dependencies so not sure it makes sense to add them to coretests at this point ?
The tests that uses the core target platform and are plain core tests could go there afaics, but depend on the usecase and when these plugins will be considered "released"
> For QE it would be useful for running tests on Jenkins without building integration tests locally. Of course we can also solve this problem by creating separate update site for integration tests. I can't say what is easier.
Having a site for integration-tests might make sense if its dependencies keeps being a mix of things and never really released/tagged similar to the other plugins.
Is this *just* for running tests on jboss jenkins or your internal mchydra jenkins tests ?
/max
13 years, 3 months
JBDS 6.0.0.Beta2 on Early Access
by Nick Boldt
JBDS 6.0.0.Beta2 Early Access installers are now available!
https://devstudio.jboss.com/earlyaccess/
Note that bits may take a while to replicate from our staging server to
publication. Please allow at least an hour before attempting to download
them - if the page above still shows the previous milestone instead of
6.0.0.Beta2, try again later.
--
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
http://nick.divbyzero.com
13 years, 3 months
Next-generation VPE - Visual Page Viewer (VPV)
by Yahor Radtsevich
Hi All!
There are some thoughts on the future development of VPE. Would be great to
hear any feedback/comments.
The idea is to add to VPE the must have features, like the support of
JavaScript and HTML5 and the support of 64-bit JVM on all OS. And get rid
of all less important features and the features that do not work very well
(i.e. editing - that is why we call it 'viewer').
*Why VPE needs significant changes/rewriting?*
Because of three things (at least):
- Currently VPE does not support JavaScript.
- Currently VPE is based on XULRunner 1.9 and XPCOM, which means that:
- This is not a default browser engine for Eclipse. This is the
reason of many incompatibility issues such as JVM crashes on some
workstations.
- 64-bit JVM is not supported on Windows and OSX.
- No HTML5 support (yes, we simulate HTML5 tags, but it is not
enough).
- We have to ship XULRunner with JBoss Tools/JBDS
- There are a lot of features in VPE which are working not very well,
and still make the code to be complicated and bug-prone (i.e. visual
editing or D&D). These features are spread on all code, it is not easy to
isolate them and get rid of them without rewriting a significant part of
VPE.
*How does VPE work now?*
VPE has a visual DOM builder and a lot of templates. For every XML/HTML
file opened in an editor, WTP automatically creates a W3C DOM tree (source
tree). Using templates, the visual DOM builder converts all nodes from the
source tree directly into XULRunner DOM tree (visual tree).
*So, what is wrong here:*
- We cannot use any browser other than XULRunner, because VPE templates
and the whole VPE code is tight coupled with XULRunner interfaces.
- We cannot enable JavaScript. We store Java objects for every XULRunner
node. If the visual tree is modified by JavaScript, we will get errors.
- JUnits are slow, we cannot run JUnits to test templates without
rendering them in XULRunner.
*VPV architecrture*
My vision is that the main process of the source to visual conversion
should looks like this:
*W3C source DOM--(by W3C DOM based templates)-->W3C visual DOM->HTTP
server->SWT browser widget*
*
*
The explanation follows.
*Why W3C visual DOM by W3C DOM based templates?*
Under W3C DOM based templates I mean that these templates will use
org.w3c.dom.* interfaces to produce visual DOM. To create W3C templates we
should rewrite all our existing VPE XPCOM based templates (~150 Java
classes) and many core classes. It is a lot of work, but as a bonus I
expect them to simplify significantly.
There are two not so good alternatives:
- Leave XULRunner DOM based templates as is and create wrappers for W3C
DOM nodes. So the templates will ‘think’ that they are creating XULRunner
DOM, but actually W3C DOM will be created.
- It is a simple to implement approach, but potentially it produces a
lot of runtime errors. E.g. if a template uses getStyle method, which does
not exist in W3C DOM, we will get a not implemented exception.
- Leave XULRunner DOM based templates as is and create wrappers for
browser nodes.
- Simpler than the previous approach, but slower and requires to build
visual DOM in the UI thread.
*Why HTTP server?*
It is a simple way to know what resources our browser needs and send them
on request.
There are two not so good alternatives too:
- Use browser.setText(htmlText)
- In this case the browser do not have a base URL, so we should replace
all relative links to resources in the htmlText to absolute links, like
“style.css”->“file:///foo/barproject/style.css”. And this is not enough -if
linked resources have relative links, we should replace them too. But how
we can replace these links in linked resources if we cannot change them?
The answer is we should embed these resources in htmlText, like “<link
href=style.css>”->“<style>style.css content here</styles>”. This approach
is implemented in VPE. It is very complicated. What is worse, it does not
work with JavaScript, where you can load resources as you want, e.g.
link.href = ‘style’ + ‘.’ + ‘css’ - what poor VPE can do? Interpret
JavaScipt? No.
- Create a temporary directory, copy converted .html file and ALL
resources there (because we do not know which resources are needed
exactly). Then point our browser to it:
browser.setUrl(“/temp/dir/converted.html”).
- Synchronization problems: have to manage tons of files, delete them if
not needed etc. Speed problems: all resources should be deployed to the
temporary folder before viewing the converted html in browser.
*We are going to open a TCP port, what about security?*
No problem here. Java allows to restrict connections to localhost only:
new ServerSocket(8383, 0, InetAddress.getByName("localhost"))
At least the standard Windows firewall does not worry and does not show the
“Security alert” pop-up.
*How hard to write our own HTTP server? Is not it easier to reuse something
like Jetty?*
We do not need a complicated server. Just a server which supports GET
requests would be enough. Writing of a custom server is the simplest task
ever :) Here is an
example<http://cs.au.dk/~amoeller/WWW/javaweb/server.html>of a 150
lines HTTP server with support of GET requests, MIME types and
response codes.
--
Best Regards,
Yahor Radtsevich
13 years, 3 months
Eclipse & Windows users - what is your ssh keys directory?
by André Dietisheim
Hi
I'm investigating some issue in JBoss Tools for OpenShift which is
related to ssh keys. The issue is only occurring for windows users. I'd
love if the Windows users among you guys could report me in what folder
your ssh keys are:
* C:\Users\<userid>\ssh\
OR
* C:\Users\<userid>\.ssh\
Thanks a lot for your replies!
Cheers
André
13 years, 3 months
Special profile for java 1.7 on mac - how to do it
by Martin Malina
Hi Mickael and Nick,
We've been having a problem with running our bot tests on OS X with java 1.7. This is what we get:
java.awt.AWTException: headless environment
To overcome this, we need to add this property to the tycho surefire argLine: -Dawt.toolkit=sun.lwawt.macosx.LWCToolkit
The question is how to do it?
We tried this:
<profiles>
<profile>
<id>mac17</id>
<activation>
<os>
<family>mac</family>
</os>
<jdk>1.7</jdk>
</activation>
<properties>
<systemProperties>-Dawt.toolkit=sun.lwawt.macosx.LWCToolkit</systemProperties>
</properties>
</profile>
But the problem is that maven uses OR with multiple conditions instead of AND (there has been an open bug report for this for a couple of years).
Do you have any idea how to overcome this? Of course you can always manually enable such profile, but that's not really an option if you want to run a matrix job in Jenkins.
Also, if we find a solution for this, could we add it to the parent pom?
Thanks,
Martin
--
Martin Malina
JBoss QA Engineer
Red Hat Czech s.r.o.
Purkynova 99
612 45 Brno, Czech Republic
Tel.: +420 532 294 265
13 years, 3 months
Beta2 / CR1 status :: Branched for 4.0.x, code frozen, test failures need your attention!
by Nick Boldt
Beta2 is nearly ready for release, though I haven't heard a thumbs up
from QE yet, so I didn't release it to jboss.org or devstudio.jboss.com.
I expect we'll put it out Mon or Tues.
---
JBoss Tools is branched for CR1, which means all the projects in Github
have a new "jbosstools-4.0.x" branch, eg.,
https://github.com/jbosstools/jbosstools-base/tree/jbosstools-4.0.x
https://github.com/jbosstools/jbosstools-central/tree/jbosstools-4.0.x
...
Note that we are *code frozen*, which means only urgent fixes should be
done in the branch, AFTER BEING APPROVED via +1s in JIRA.
---
Builds are underway, despite blocking test failures:
* AS: https://issues.jboss.org/browse/JBIDE-13098
* Archives: https://issues.jboss.org/browse/JBIDE-13099
* Common: https://issues.jboss.org/browse/JBIDE-13097
* Hibernate: https://issues.jboss.org/browse/JBIDE-12849 (broken since
Beta1)
* Seam (JavaEE): https://issues.jboss.org/browse/JBIDE-13101
* VPE: https://issues.jboss.org/browse/JBIDE-13100
* Portlet: respinning now, was waiting on a JavaEE build
* Central/Maven/Examples: waiting on a clean Portlet build
Remember, Operation Blue Balls begins with you! :)
---
Github master branches are now set to be 4.1.0.Alpha1. This is for the
moment a placeholder, as we don't for sure know if the next release will
be a 4.0.1 or a 4.1.0.
We have NOT yet moved the trunk/master to a Kepler Target Platform -
that will probably wait until December. For now, consider the github
master branches and the devstudio SVN trunk FROZEN.
If you have new work you need to do, be it for a JBT4.0.1/JunoSR2
build or a JBT4.x/Kepler build, do so in a private topic branch.
Thanks!
--
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
http://nick.divbyzero.com
13 years, 3 months
